| |
| RFC 7200 | A Session Initiation Protocol (SIP) Load-Control Event Package |
| |
| Authors: | C. Shen, H. Schulzrinne, A. Koike. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7200 |
|
This specification defines a load-control event package for theSession 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. |
|
| |
| RFC 7201 | Options for Securing RTP Sessions |
| |
| Authors: | M. Westerlund, C. Perkins. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7201 |
|
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. |
|
| |
| RFC 7202 | Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution |
| |
| Authors: | C. Perkins, M. Westerlund. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7202 |
|
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. |
|
| |
| RFC 7203 | An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information |
| |
| Authors: | T. Takahashi, K. Landfield, Y. Kadobayashi. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7203 |
|
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. |
|
| |
| RFC 7204 | Requirements for Labeled NFS |
| |
| Authors: | T. Haynes. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7204 |
|
This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into theNetwork 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. |
|
| |
| RFC 7205 | Use Cases for Telepresence Multistreams |
| |
| Authors: | A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7205 |
|
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. |
|
| |
| RFC 7206 | Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks |
| |
| Authors: | P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7206 |
|
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. |
|
| |
| RFC 7207 | A Uniform Resource Name (URN) Namespace for Eurosystem Messaging |
| |
| Authors: | M. Ortseifen, G. Dickfeld. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7207 |
|
This document defines and registers with IANA a Uniform Resource Name(URN) namespace for usage within messages standardized by theEurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB). |
|
| |
| RFC 7208 | Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |
| |
|
|
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 ADministrativeManagement 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. |
|
| |
| RFC 7209 | Requirements for Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7209 |
|
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 leverageMultipoint-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. |
|
| |
| RFC 7210 | Database of Long-Lived Symmetric Cryptographic Keys |
| |
| Authors: | R. Housley, T. Polk, S. Hartman, D. Zhang. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7210 |
|
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. |
|
| |
| RFC 7211 | Operations Model for Router Keying |
| |
| Authors: | S. Hartman, D. Zhang. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7211 |
|
The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed inRFC 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. |
|
| |
| RFC 7212 | MPLS Generic Associated Channel (G-ACh) Advertisement Protocol |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7212 |
|
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. |
|
| |
| RFC 7213 | MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7213 |
|
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. |
|
| |
| RFC 7214 | Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry |
| |
|
|
RFC 5586 generalized the applicability of the pseudowire AssociatedChannel 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 SwitchingArchitecture (MPLS)" heading. This document updates RFC 5586.
This document also updates RFCs 6374, 6378, 6427, and 6428. |
|
| |
| RFC 7215 | Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations |
| |
| Authors: | L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7215 |
|
This document is a snapshot of different Locator/IdentifierSeparation 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 Summer2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding. |
|
| |
| RFC 7216 | Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS |
| |
| Authors: | M. Thomson, R. Bellis. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7216 |
|
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location InformationServer (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. |
|
| |
| RFC 7217 | A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) |
| |
| Authors: | F. Gont. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7217 |
|
This document specifies a method for generating IPv6 InterfaceIdentifiers 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). |
|
| |
| RFC 7218 | Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) |
| |
|
|
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 RFC6698. |
|
| |
| RFC 7219 | SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) |
| |
| Authors: | M. Bagnulo, A. Garcia-Martinez. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7219 |
|
This memo specifies SEcure Neighbor Discovery (SEND) Source AddressValidation 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. |
|
| |
| RFC 7220 | Description Option for the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7220 |
|
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. |
|
| |
| RFC 7221 | Handling of Internet-Drafts by IETF Working Groups |
| |
| Authors: | A. Farrel, D. Crocker, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7221 |
|
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. |
|
| |
| RFC 7222 | Quality-of-Service Option for Proxy Mobile IPv6 |
| |
| Authors: | M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7222 |
|
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. |
|
| |
| RFC 7223 | A YANG Data Model for Interface Management |
| |
|
|
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). |
|
| |
| RFC 7224 | IANA Interface Type YANG Module |
| |
| Authors: | M. Bjorklund. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7224 |
|
This document defines the initial version of the iana-if-type YANG module. |
|
| |
| RFC 7225 | Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7225 |
|
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. |
|
| |
| RFC 7226 | Requirements for Advanced Multipath in MPLS Networks |
| |
| Authors: | C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7226 |
|
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. |
|
| |
| RFC 7227 | Guidelines for Creating New DHCPv6 Options |
| |
| Authors: | D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updates: | RFC 3315 |
| Also: | BCP 0187 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7227 |
|
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. |
|
| |
| RFC 7228 | Terminology for Constrained-Node Networks |
| |
| Authors: | C. Bormann, M. Ersue, A. Keranen. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7228 |
|
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. |
|
| |
| RFC 7229 | Object Identifiers for Test Certificate Policies |
| |
| Authors: | R. Housley. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7229 |
|
This document provides several certificate policy identifiers for testing certificate handling software. |
|
| |
| RFC 7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| |
|
|
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" UniformResource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. |
|
| |
| RFC 7231 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| |
|
|
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. |
|
| |
| RFC 7232 | Hypertext Transfer Protocol (HTTP/1.1): 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. |
|
| |
| RFC 7233 | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| |
| Authors: | R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7233 |
|
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. |
|
| |
| RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9111 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7234 |
|
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. |
|
| |
| RFC 7235 | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. |
|
| |
| RFC 7236 | Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations |
| |
| Authors: | J. Reschke. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7236 |
|
This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANAHTTP Authentication Scheme Registry was established. |
|
| |
| RFC 7237 | Initial Hypertext Transfer Protocol (HTTP) Method Registrations |
| |
| Authors: | J. Reschke. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7237 |
|
This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP MethodRegistry was established. |
|
| |
| RFC 7238 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7239 | Forwarded HTTP Extension |
| |
| Authors: | A. Petersson, M. Nilsson. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7239 |
|
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. |
|
| |
| RFC 7240 | Prefer Header for HTTP |
| |
|
|
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. |
|
| |
| RFC 7241 | The IEEE 802/IETF Relationship |
| |
| Authors: | S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. |
| Date: | July 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4441 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7241 |
|
This document describes the standardization cooperation betweenProject 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. |
|
| |
| RFC 7242 | Delay-Tolerant Networking TCP Convergence-Layer Protocol |
| |
| Authors: | M. Demmer, J. Ott, S. Perreault. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7242 |
|
This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of theIRTF's DTN Research Group (DTNRG). |
|
| |
| RFC 7243 | RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric |
| |
| Authors: | V. Singh, Ed., J. Ott, I. Curcio. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7243 |
|
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. |
|
| |
| RFC 7244 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting |
| |
| Authors: | H. Asaeda, Q. Wu, R. Huang. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7244 |
|
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. |
|
| |
| RFC 7245 | An Architecture for Media Recording Using the Session Initiation Protocol |
| |
| Authors: | A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7245 |
|
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). |
|
| |
| RFC 7246 | Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context |
| |
| Authors: | IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. |
| Date: | June 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7246 |
|
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 IPMDT, 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 hybridMDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label DistributionProtocol (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. |
|
| |
| RFC 7247 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7247 |
|
As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the ExtensibleMessaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. |
|
| |
| RFC 7248 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | May 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8048 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7248 |
|
This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). |
|
| |
| RFC 7249 | Internet Numbers Registries |
| |
| Authors: | R. Housley. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7249 |
|
RFC 7020 provides information about the Internet Numbers RegistrySystem 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. |
|
| |
| RFC 7250 | Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7250 |
|
This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. |
|
| |
| RFC 7251 | AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS |
| |
| Authors: | D. McGrew, D. Bailey, M. Campagna, R. Dugal. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7251 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within TransportLayer 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 CurveCryptography (ECC) and are advantageous in networks with limited bandwidth. |
|
| |
| RFC 7252 | The Constrained Application Protocol (CoAP) |
| |
|
|
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 andInternet 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. |
|
| |
| RFC 7253 | The OCB Authenticated-Encryption Algorithm |
| |
| Authors: | T. Krovetz, P. Rogaway. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7253 |
|
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). |
|
| |
| RFC 7254 | A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) |
| |
| Authors: | M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7254 |
|
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 SoftwareVersion number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the3rd 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 andIMEISV 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. |
|
| |
| RFC 7255 | Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID |
| |
| Authors: | A. Allen, Ed.. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7255 |
|
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 specificURN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior. |
|
| |
| RFC 7256 | Multicast Control Extensions for the Access Node Control Protocol (ANCP) |
| |
| Authors: | F. Le Faucheur, R. Maglione, T. Taylor. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updates: | RFC 6320 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7256 |
|
This document specifies the extensions to the Access Node ControlProtocol (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 IETFConsensus from 0x100 to 0x64. |
|
| |
| RFC 7257 | Virtual Private LAN Service (VPLS) Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7257 |
|
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). |
|
| |
| RFC 7258 | Pervasive Monitoring Is an Attack |
| |
| Authors: | S. Farrell, H. Tschofenig. |
| Date: | May 2014 |
| Formats: | txt html json |
| Also: | BCP 0188 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7258 |
|
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. |
|
| |
| RFC 7259 | The Jabber-ID Header Field |
| |
| Authors: | P. Saint-Andre. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7259 |
|
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 particularExtensible Messaging and Presence Protocol (XMPP) address. |
|
| |
| RFC 7260 | GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration |
| |
| Authors: | A. Takacs, D. Fedyk, J. He. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7260 |
|
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 configureOAM entities. This document specifies extensions to ResourceReservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with LabelSwitched Path signaling. |
|
| |
| RFC 7261 | Offer/Answer Considerations for G723 Annex A and G729 Annex B |
| |
| Authors: | M. Perumal, P. Ravindran. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7261 |
|
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. |
|
| |
| RFC 7262 | Requirements for Telepresence Multistreams |
| |
| Authors: | A. Romanow, S. Botzko, M. Barnes. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7262 |
|
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. |
|
| |
| RFC 7263 | An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing |
| |
| Authors: | N. Zong, X. Jiang, R. Even, Y. Zhang. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7263 |
|
This document defines an optional extension to the REsource LOcationAnd 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. |
|
| |
| RFC 7264 | An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing |
| |
| Authors: | N. Zong, X. Jiang, R. Even, Y. Zhang. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7264 |
|
This document defines an optional extension to the REsource LOcationAnd 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. |
|
| |
| RFC 7265 | jCal: The JSON Format for iCalendar |
| |
| Authors: | P. Kewisch, C. Daboo, M. Douglass. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7529 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7265 |
|
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. |
|
| |
| RFC 7266 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting |
| |
| Authors: | A. Clark, Q. Wu, R. Schott, G. Zorn. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7266 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block including two new segment types and associated SessionDescription Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications. |
|
| |
| RFC 7267 | Dynamic Placement of Multi-Segment Pseudowires |
| |
| Authors: | L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed.. |
| Date: | June 2014 |
| Formats: | txt json html |
| Updates: | RFC 6073 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7267 |
|
RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet SwitchedNetwork 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. |
|
| |
| RFC 7268 | RADIUS Attributes for IEEE 802 Networks |
| |
|
|
RFC 3580 provides guidelines for the use of the Remote AuthenticationDial-In User Service (RADIUS) within IEEE 802 local area networks(LANs). This document defines additional attributes for use withinIEEE 802 networks and clarifies the usage of the EAP-Key-NameAttribute and the Called-Station-Id Attribute. This document updatesRFCs 3580 and 4072. |
|
| |
| RFC 7269 | NAT64 Deployment Options and Experience |
| |
| Authors: | G. Chen, Z. Cao, C. Xie, D. Binet. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7269 |
|
This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) andNAT64 server Front End (NAT64-FE) are considered in this document. |
|
| |
| RFC 7270 | Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) |
| |
| Authors: | A. Yourtchenko, P. Aitken, B. Claise. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7270 |
|
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 RFC3954, as specified in the IPFIX Information Model in RFC 7012. |
|
| |
| RFC 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 |
| |
| Authors: | J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 6378 |
| Updated by: | RFC 8234 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7271 |
|
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 AutomaticProtection 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. |
|
| |
| RFC 7272 | Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) |
| |
| Authors: | R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7272 |
|
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achievingInter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using theRTCP 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 SettingsPacket 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. |
|
| |
| RFC 7273 | RTP Clock Source Signalling |
| |
| Authors: | A. Williams, K. Gross, R. van Brandenburg, H. Stokking. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7273 |
|
NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifiesSession Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session. |
|
| |
| RFC 7274 | Allocating and Retiring Special-Purpose MPLS Labels |
| |
| Authors: | K. Kompella, L. Andersson, A. Farrel. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790 |
| Updated by: | RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7274 |
|
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 MPLSLabel Values" and creates a new registry called the "ExtendedSpecial-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, and6790. |
|
| |
| RFC 7275 | Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy |
| |
| Authors: | L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7275 |
|
This document specifies an Inter-Chassis Communication Protocol(ICCP) that enables Provider Edge (PE) device redundancy for VirtualPrivate 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. |
|
| |
| RFC 7276 | An Overview of Operations, Administration, and Maintenance (OAM) Tools |
| |
| Authors: | T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7276 |
|
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. |
|
| |
| RFC 7277 | A YANG Data Model for IP Management |
| |
|
|
This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data. |
|
| |
| RFC 7278 | Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link |
| |
| Authors: | C. Byrne, D. Drown, A. Vizdal. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7278 |
|
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. |
|
| |
| RFC 7279 | An Acceptable Use Policy for New ICMP Types and Codes |
| |
|
|
In this document we provide a basic description of ICMP's role in theIP 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. |
|
| |
| RFC 7280 | IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry |
| |
|
|
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 StreamEncapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols. |
|
| |
| RFC 7281 | Authentication-Results Registration for S/MIME Signature Verification |
| |
| Authors: | A. Melnikov. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7281 |
|
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. |
|
| |
| RFC 7282 | On Consensus and Humming in the IETF |
| |
| Authors: | P. Resnick. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7282 |
|
The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views amongIETF 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 asInformational. 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. |
|
| |
| RFC 7283 | Handling Unknown DHCPv6 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. |
|
| |
| RFC 7284 | The Profile URI Registry |
| |
| Authors: | M. Lanthaler. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7284 |
|
This document defines a registry for profile URIs to be used in specifications standardizing profiles. |
|
| |
| RFC 7285 | Application-Layer Traffic Optimization (ALTO) Protocol |
| |
| Authors: | R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. |
| Date: | September 2014 |
| Formats: | txt html json |
| Updated by: | RFC 9274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7285 |
|
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. |
|
| |
| RFC 7286 | Application-Layer Traffic Optimization (ALTO) Server Discovery |
| |
| Authors: | S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7286 |
|
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 anALTO client can ask for guidance, it needs to discover one or moreALTO servers.
This document specifies a procedure for resource-consumer-initiatedALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. |
|
| |
| RFC 7287 | Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains |
| |
| Authors: | T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7287 |
|
Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying MulticastListener 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. |
|
| |
| RFC 7288 | Reflections on Host Firewalls |
| |
| Authors: | D. Thaler. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7288 |
|
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. |
|
| |
| RFC 7289 | Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs |
| |
| Authors: | V. Kuarsingh, Ed., J. Cianfarani. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7289 |
|
This document specifies a framework to integrate a Network AddressTranslation (NAT) layer into an operator's network to function as aCarrier-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 IPVPNs, which allow for virtual routing separation, helping ease theCGN's impact on the network. This document does not intend to defend the merits of CGN. |
|
| |
| RFC 7290 | Test Plan and Results for Advancing RFC 2680 on the Standards Track |
| |
| Authors: | L. Ciavattone, R. Geib, A. Morton, M. Wieser. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7290 |
|
This memo provides the supporting test plan and results to advanceRFC 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. |
|
| |
| RFC 7291 | DHCP Options for the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7291 |
|
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. |
|
| |
| RFC 7292 | PKCS #12: Personal Information Exchange Syntax v1.1 |
| |
| Authors: | K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9579 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7292 |
|
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 RSALaboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. |
|
| |
| RFC 7293 | The Require-Recipient-Valid-Since Header Field and SMTP Service Extension |
| |
| Authors: | W. Mills, M. Kucherawy. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7293 |
|
This document defines an extension for the Simple Mail TransferProtocol (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. |
|
| |
| RFC 7294 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications |
| |
| Authors: | A. Clark, G. Zorn, C. Bi, Q. Wu. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7294 |
|
This document defines two RTP Control Protocol (RTCP) Extended Report(XR) blocks that allow the reporting of concealment metrics for audio applications of RTP. |
|
| |
| RFC 7295 | Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication |
| |
| Authors: | H. Tschofenig, L. Eggert, Z. Sarker. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7295 |
|
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 InternetEngineering 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 theInternet Research Task Force (IRTF). |
|
| |
| RFC 7296 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
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. |
|
| |
| RFC 7297 | IP Connectivity Provisioning Profile (CPP) |
| |
| Authors: | M. Boucadair, C. Jacquenet, N. Wang. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7297 |
|
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 ofTraffic Engineering functions and service management functions, and(3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. |
|
| |
| RFC 7298 | Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication |
| |
|
|
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. |
|
| |
| RFC 7299 | Object Identifier Registry for the PKIX Working Group |
| |
|
|
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. |
|
