| |
| RFC 7300 | Reservation of Last Autonomous System (AS) Numbers |
| |
|
|
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. |
|
| |
| RFC 7301 | Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension |
| |
| Authors: | S. Friedl, A. Popov, A. Langley, E. Stephan. |
| Date: | July 2014 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7301 |
|
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. |
|
| |
| RFC 7302 | Entertainment Identifier Registry (EIDR) URN Namespace Definition |
| |
|
|
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. |
|
| |
| RFC 7303 | XML Media Types |
| |
|
|
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 theExtensible 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. |
|
| |
| RFC 7304 | A Method for Mitigating Namespace Collisions |
| |
| Authors: | W. Kumari. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7304 |
|
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. |
|
| |
| RFC 7305 | Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) |
| |
| Authors: | E. Lear, Ed.. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7305 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Internet Technology Adoption andTransition (ITAT). The workshop was hosted by the University ofCambridge 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. |
|
| |
| RFC 7306 | Remote Direct Memory Access (RDMA) Protocol Extensions |
| |
| Authors: | H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7306 |
|
This document specifies extensions to the IETF Remote Direct MemoryAccess 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. |
|
| |
| RFC 7307 | LDP Extensions for Multi-Topology |
| |
| Authors: | Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7307 |
|
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing withinMultiprotocol 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. |
|
| |
| RFC 7308 | Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) |
| |
| Authors: | E. Osborne. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7308 |
|
MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using theAdministrative 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, "ExtendedAdministrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. |
|
| |
| RFC 7309 | Redundancy Mechanism for Inter-domain VPLS Service |
| |
| Authors: | Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7309 |
|
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-domainVPLS solution that provides PE node redundancy across domains. |
|
| |
| RFC 7310 | RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs |
| |
| Authors: | J. Lindsay, H. Foerster. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7310 |
|
This document specifies a scheme for packetizing Standard apt-X orEnhanced 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). |
|
| |
| RFC 7311 | The Accumulated IGP Metric Attribute for BGP |
| |
| Authors: | P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7311 |
|
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. |
|
| |
| RFC 7312 | Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) |
| |
|
|
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 theIP 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. |
|
| |
| RFC 7313 | Enhanced Route Refresh Capability for BGP-4 |
| |
| Authors: | K. Patel, E. Chen, B. Venkatachalapathy. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updates: | RFC 2918 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7313 |
|
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. |
|
| |
| RFC 7314 | Extension Mechanisms for DNS (EDNS) EXPIRE Option |
| |
| Authors: | M. Andrews. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7314 |
|
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. |
|
| |
| RFC 7315 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP |
| |
|
|
This document describes a set of private header (P-header) SessionInitiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. TheP-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. |
|
| |
| RFC 7316 | The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) |
| |
| Authors: | J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7316 |
|
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. |
|
| |
| RFC 7317 | A YANG Data Model for System Management |
| |
| Authors: | A. Bierman, M. Bjorklund. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7317 |
|
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. |
|
| |
| RFC 7318 | Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates |
| |
|
|
This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource PublicKey Infrastructure (RPKI) resource certificates. |
|
| |
| RFC 7319 | IANA Considerations for Connectivity Fault Management (CFM) Code Points |
| |
|
|
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. |
|
| |
| RFC 7320 | URI Design and Ownership |
| |
|
|
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. |
|
| |
| RFC 7321 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
This document updates the Cryptographic Algorithm ImplementationRequirements for the Encapsulating Security Payload (ESP) andAuthentication 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.
This document obsoletes RFC 4835. |
|
| |
| RFC 7322 | RFC Style Guide |
| |
|
|
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". |
|
| |
| RFC 7323 | TCP Extensions for High Performance |
| |
| Authors: | D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.. |
| Date: | September 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 1323 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7323 |
|
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 WrappedSequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
This document obsoletes RFC 1323 and describes changes from it. |
|
| |
| RFC 7324 | Updates to MPLS Transport Profile Linear Protection |
| |
|
|
This document contains a number of updates to the Protection StateCoordination (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. |
|
| |
| RFC 7325 | MPLS Forwarding Compliance and Performance Requirements |
| |
| Authors: | C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7325 |
|
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 that are unstated or underemphasized, or that are optional for conformance to RFCs but often considered mandatory by providers. |
|
| |
| RFC 7326 | Energy Management Framework |
| |
| Authors: | J. Parello, B. Claise, B. Schoening, J. Quittek. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7326 |
|
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 EnergyManagement Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. EnergyObjects can be monitored and controlled with respect to power, PowerState, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between EnergyObjects. |
|
| |
| RFC 7328 | Writing I-Ds and RFCs Using Pandoc and a Bit of XML |
| |
| Authors: | R. Gieben. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7328 |
|
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) orRFCs.
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. |
|
| |
| RFC 7329 | A Session Identifier for the Session Initiation Protocol (SIP) |
| |
|
|
There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIPProxies, 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 newStandards Track document produced by the INSIPID Working Group. |
|
| |
| RFC 7330 | Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management |
| |
| Authors: | T. Nadeau, Z. Ali, N. Akiya. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7330 |
|
This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly usedBidirectional 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. |
|
| |
| RFC 7331 | Bidirectional Forwarding Detection (BFD) Management Information Base |
| |
| Authors: | T. Nadeau, Z. Ali, N. Akiya. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7331 |
|
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. |
|
| |
| RFC 7332 | Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | H. Kaplan, V. Pascual. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7332 |
|
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. |
|
| |
| RFC 7333 | Requirements for Distributed Mobility Management |
| |
| Authors: | H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7333 |
|
This document defines the requirements for Distributed MobilityManagement (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. |
|
| |
| RFC 7334 | PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7334 |
|
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 ofP2MP 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. |
|
| |
| RFC 7335 | IPv4 Service Continuity Prefix |
| |
|
|
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. |
|
| |
| RFC 7336 | Framework for Content Distribution Network Interconnection (CDNI) |
| |
| Authors: | L. Peterson, B. Davie, R. van Brandenburg, Ed.. |
| Date: | August 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 3466 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7336 |
|
This document presents a framework for Content Distribution NetworkInterconnection (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 interconnectCDNs. 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, obsoletesRFC 3466. |
|
| |
| RFC 7337 | Content Distribution Network Interconnection (CDNI) Requirements |
| |
| Authors: | K. Leung, Ed., Y. Lee, Ed.. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7337 |
|
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, existingCDN providers are scaling up their infrastructure. Many NetworkService Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the ContentService 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. |
|
| |
| RFC 7338 | Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks |
| |
| Authors: | F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7338 |
|
This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS PacketSwitched 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). |
|
| |
| RFC 7339 | Session Initiation Protocol (SIP) Overload Control |
| |
| Authors: | V. Gurbani, Ed., V. Hilt, H. Schulzrinne. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7339 |
|
Overload occurs in Session Initiation Protocol (SIP) networks whenSIP 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 (ServiceUnavailable) 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. |
|
| |
| RFC 7340 | Secure Telephone Identity Problem Statement and Requirements |
| |
| Authors: | J. Peterson, H. Schulzrinne, H. Tschofenig. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7340 |
|
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. |
|
| |
| RFC 7341 | DHCPv4-over-DHCPv6 (DHCP 4o6) Transport |
| |
| Authors: | Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7341 |
|
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. |
|
| |
| RFC 7342 | Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers |
| |
| Authors: | L. Dunbar, W. Kumari, I. Gashinsky. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7342 |
|
This memo documents some operational practices that allow ARP andNeighbor Discovery (ND) to scale in data center environments. |
|
| |
| RFC 7343 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) |
| |
|
|
This document specifies an updated Overlay Routable CryptographicHash 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. |
|
| |
| RFC 7344 | Automating DNSSEC Delegation Trust Maintenance |
| |
| Authors: | W. Kumari, O. Gudmundsson, G. Barwood. |
| Date: | September 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8078 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7344 |
|
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. |
|
| |
| RFC 7345 | UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) |
| |
| Authors: | C. Holmberg, I. Sedlacek, G. Salgueiro. |
| Date: | August 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7345 |
|
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 DescriptionProtocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). |
|
| |
| RFC 7346 | IPv6 Multicast Address Scopes |
| |
|
|
This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291. |
|
| |
| RFC 7347 | Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro. |
| Date: | September 2014 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7347 |
|
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-TPLinear 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. |
|
| |
| RFC 7348 | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| Authors: | M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7348 |
|
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. |
|
| |
| RFC 7349 | LDP Hello Cryptographic Authentication |
| |
| Authors: | L. Zheng, M. Chen, M. Bhatia. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7349 |
|
This document introduces a new optional Cryptographic AuthenticationTLV that LDP can use to secure its Hello messages. It secures theHello 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. |
|
| |
| RFC 7350 | Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) |
| |
|
|
This document specifies the usage of Datagram Transport LayerSecurity (DTLS) as a transport protocol for Session TraversalUtilities 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. |
|
| |
| RFC 7351 | A Media Type for XML Patch Operations |
| |
| Authors: | E. Wilde. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7351 |
|
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. |
|
| |
| RFC 7352 | Sieve Email Filtering: Detecting Duplicate Deliveries |
| |
| Authors: | S. Bosch. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7352 |
|
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. |
|
| |
| RFC 7353 | Security Requirements for BGP Path Validation |
| |
| Authors: | S. Bellovin, R. Bush, D. Ward. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7353 |
|
This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AutonomousSystem (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement. |
|
| |
| RFC 7354 | Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace |
| |
|
|
RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updatesRFC 5328 with new registrant information. |
|
| |
| RFC 7355 | Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) |
| |
| Authors: | G. Salgueiro, V. Pascual, A. Roman, S. Garcia. |
| Date: | September 2014 |
| Formats: | txt json html |
| Updates: | RFC 6873 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7355 |
|
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 RFC6873, with a new "Transport Flag" for such SIP WebSocket transport. |
|
| |
| RFC 7356 | IS-IS Flooding Scope Link State PDUs (LSPs) |
| |
| Authors: | L. Ginsberg, S. Previdi, Y. Yang. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7356 |
|
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. |
|
| |
| RFC 7357 | Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol |
| |
| Authors: | H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes. |
| Date: | September 2014 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7357 |
|
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. |
|
| |
| RFC 7358 | Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) |
| |
|
|
The label advertising behavior of an LDP speaker for a givenForwarding 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. |
|
| |
| RFC 7359 | Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks |
| |
| Authors: | F. Gont. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7359 |
|
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. |
|
| |
| RFC 7360 | Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS |
| |
| Authors: | A. DeKok. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7360 |
|
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 LayerSecurity (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. |
|
| |
| RFC 7361 | LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) |
| |
| Authors: | P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7361 |
|
RFC 4762 describes a mechanism to remove or unlearn Media AccessControl (MAC) addresses that have been dynamically learned in aVirtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in theVPLS 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 theProvider Backbone Bridging (PBB) VPLS specified in RFC 7041. |
|
| |
| RFC 7362 | Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication |
| |
| Authors: | E. Ivov, H. Kaplan, D. Wing. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7362 |
|
This document describes the behavior of signaling intermediaries inReal-Time Communication (RTC) deployments, sometimes referred to asSession Border Controllers (SBCs), when performing Hosted NATTraversal (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 InteractiveConnectivity Establishment (ICE) protocol. |
|
| |
| RFC 7363 | Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Maenpaa, G. Camarillo. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7363 |
|
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. |
|
| |
| RFC 7364 | Problem Statement: Overlays for Network Virtualization |
| |
| Authors: | T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7364 |
|
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. |
|
| |
| RFC 7365 | Framework for Data Center (DC) Network Virtualization |
| |
| Authors: | M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7365 |
|
This document provides a framework for Data Center (DC) NetworkVirtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution. |
|
| |
| RFC 7366 | Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | P. Gutmann. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7366 |
|
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 DatagramTransport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years. |
|
| |
| RFC 7367 | Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process |
| |
| Authors: | R. Cole, J. Macker, B. Adamson. |
| Date: | October 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7367 |
|
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 theSimplified Multicast Forwarding (SMF) process for Mobile Ad HocNetworks (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. |
|
| |
| RFC 7368 | IPv6 Home Networking Architecture Principles |
| |
| Authors: | T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7368 |
|
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. |
|
| |
| RFC 7369 | GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration |
| |
| Authors: | A. Takacs, B. Gero, H. Long. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7369 |
|
The work related to GMPLS Ethernet Label Switching (GELS) extendedGMPLS RSVP-TE to support the establishment of Ethernet LabelSwitching Paths (LSPs). IEEE Ethernet Connectivity Fault Management(CFM) specifies an adjunct Operations, Administration, andMaintenance (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, includingPerformance 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 OAMConfiguration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms. |
|
| |
| RFC 7370 | Updates to the IS-IS TLV Codepoints Registry |
| |
|
|
This document recommends some editorial changes to the IANA "IS-ISTLV 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. |
|
| |
| RFC 7371 | Updates to the IPv6 Multicast Addressing Architecture |
| |
|
|
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. |
|
| |
| RFC 7372 | Email Authentication Status Codes |
| |
|
|
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. |
|
| |
| RFC 7373 | Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types |
| |
| Authors: | B. Trammell. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7373 |
|
This document defines UTF-8 representations for IP Flow InformationExport (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. |
|
| |
| RFC 7374 | Service Discovery Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Maenpaa, G. Camarillo. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7374 |
|
REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC6940). This document defines how the Recursive DistributedRendezvous (ReDiR) service discovery mechanism can be applied toRELOAD overlays to provide a generic service discovery mechanism. |
|
| |
| RFC 7375 | Secure Telephone Identity Threat Model |
| |
| Authors: | J. Peterson. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7375 |
|
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. |
|
| |
| RFC 7376 | Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) |
| |
| Authors: | T. Reddy, R. Ravindranath, M. Perumal, A. Yegin. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7376 |
|
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. |
|
| |
| RFC 7377 | IMAP4 Multimailbox SEARCH Extension |
| |
|
|
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 andSEARCH 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. |
|
| |
| RFC 7378 | Trustworthy Location |
| |
| Authors: | H. Tschofenig, H. Schulzrinne, B. Aboba, Ed.. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7378 |
|
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. |
|
| |
| RFC 7379 | Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge |
| |
| Authors: | Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7379 |
|
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. |
|
| |
| RFC 7380 | RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting |
| |
| Authors: | J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7380 |
|
An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicastMPEG2 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. |
|
| |
| RFC 7381 | Enterprise IPv6 Deployment Guidelines |
| |
| Authors: | K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7381 |
|
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 anIPv6-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. |
|
| |
| RFC 7382 | Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) |
| |
| Authors: | S. Kent, D. Kong, K. Seo. |
| Date: | April 2015 |
| Formats: | txt html json |
| Also: | BCP 0173 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7382 |
|
This document contains a template to be used for creating aCertification 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. |
|
| |
| RFC 7383 | Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation |
| |
| Authors: | V. Smyslov. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7383 |
|
This document describes a way to avoid IP fragmentation of largeInternet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allowIP fragments to pass through. |
|
| |
| RFC 7384 | Security Requirements of Time Protocols in Packet Switched Networks |
| |
| Authors: | T. Mizrahi. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7384 |
|
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 thePrecision 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. |
|
| |
| RFC 7385 | IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points |
| |
|
|
RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSITunnel) attribute". However, the RFC did not create a correspondingIANA 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. |
|
| |
| RFC 7386 | JSON Merge Patch |
| |
| Authors: | P. Hoffman, J. Snell. |
| Date: | October 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7396 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7386 |
|
This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content. |
|
| |
| RFC 7387 | A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network |
| |
| Authors: | R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin. |
| Date: | October 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7387 |
|
This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over aMultiprotocol 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. |
|
| |
| RFC 7388 | Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7388 |
|
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 overLow-Power Wireless Personal Area Networks (6LoWPANs). |
|
| |
| RFC 7389 | Separation of Control and User Plane for Proxy Mobile IPv6 |
| |
| Authors: | R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7389 |
|
This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy MobileIPv6 (PMIPv6). Existing specifications allow a mobile access gateway(MAG) to separate its control and user plane using the AlternateCare-of Address mobility option for IPv6 or Alternate IPv4 Care-ofAddress 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. |
|
| |
| RFC 7390 | Group Communication for the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Rahman, Ed., E. Dijk, Ed.. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7390 |
|
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. |
|
| |
| RFC 7391 | Forwarding and Control Element Separation (ForCES) Protocol Extensions |
| |
|
|
Experience in implementing and deploying the Forwarding and ControlElement 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. |
|
| |
| RFC 7392 | Explicit Path Routing for Dynamic Multi-Segment Pseudowires |
| |
| Authors: | P. Dutta, M. Bocci, L. Martini. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7392 |
|
When set up through an explicit path, dynamic Multi-SegmentPseudowires (MS-PWs) may be required to provide a simple solution for1: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. |
|
| |
| RFC 7393 | Using the Port Control Protocol (PCP) to Update Dynamic DNS |
| |
| Authors: | X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7393 |
|
This document focuses on the problems encountered when using dynamicDNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) andNetwork Address and Protocol Translation from IPv6 Clients to IPv4Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo. |
|
| |
| RFC 7394 | Definition of Time to Live TLV for LSP-Ping Mechanisms |
| |
| Authors: | S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7394 |
|
LSP-Ping is a widely deployed Operation, Administration, andMaintenance (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 theMS-PW and/or bidirectional co-routed LSP. This document defines aTLV to address this shortcoming. |
|
| |
| RFC 7395 | An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket |
| |
| Authors: | L. Stout, Ed., J. Moffitt, E. Cestari. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7395 |
|
This document defines a binding for the Extensible Messaging andPresence Protocol (XMPP) over a WebSocket transport layer. AWebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. |
|
| |
| RFC 7396 | JSON Merge Patch |
| |
| Authors: | P. Hoffman, J. Snell. |
| Date: | October 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 7386 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7396 |
|
This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content. |
|
| |
| RFC 7397 | Report from the Smart Object Security Workshop |
| |
| Authors: | J. Gilger, H. Tschofenig. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7397 |
|
This document provides a summary of a workshop on 'Smart ObjectSecurity' 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. |
|
| |
| RFC 7398 | A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance |
| |
| Authors: | M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7398 |
|
This document defines a reference path for Large-scale Measurement ofBroadband 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. |
|
| |
| RFC 7399 | Unanswered Questions in the Path Computation Element Architecture |
| |
| Authors: | A. Farrel, D. King. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7399 |
|
The Path Computation Element (PCE) architecture is set out in RFC4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) inRFC 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. |
|
