| |
| RFC 7400 | 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | C. Bormann. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7400 |
|
RFC 6282 defines header compression in 6LoWPAN packets (where"6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal AreaNetwork"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. |
|
| |
| RFC 7401 | Host Identity Protocol Version 2 (HIPv2) |
| |
|
|
This document specifies the details of the Host Identity Protocol(HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.
This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. |
|
| |
| RFC 7402 | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
| Authors: | P. Jokela, R. Moskowitz, J. Melen. |
| Date: | April 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 5202 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7402 |
|
This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). This document obsoletes RFC 5202. |
|
| |
| RFC 7403 | A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Kaplan. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7403 |
|
SIP already provides the ability to perform hop-by-hop traceroute forSIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media- loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back- to-back user agents (B2BUAs). |
|
| |
| RFC 7404 | Using Only Link-Local Addressing inside an IPv6 Network |
| |
| Authors: | M. Behringer, E. Vyncke. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7404 |
|
In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network. |
|
| |
| RFC 7405 | Case-Sensitive String Support in ABNF |
| |
|
|
This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. |
|
| |
| RFC 7406 | Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices |
| |
| Authors: | H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7406 |
|
This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. |
|
| |
| RFC 7407 | A YANG Data Model for SNMP Configuration |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7407 |
|
This document defines a collection of YANG definitions for configuring SNMP engines. |
|
| |
| RFC 7408 | Forwarding and Control Element Separation (ForCES) Model Extension |
| |
|
|
This memo extends the Forwarding and Control Element Separation(ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models. |
|
| |
| RFC 7409 | Forwarding and Control Element Separation (ForCES) Packet Parallelization |
| |
| Authors: | E. Haleplidis, J. Halpern. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7409 |
|
Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation(ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810). |
|
| |
| RFC 7410 | A Property Types Registry for the Authentication-Results Header Field |
| |
|
|
This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. |
|
| |
| RFC 7411 | Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers |
| |
| Authors: | T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. |
| Date: | November 2014 |
| Formats: | txt json html |
| Updates: | RFC 5568 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7411 |
|
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6(PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the MobileIPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy MobileIPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy RouterAdvertisements message format.
This document updates RFC 5568, "Mobile IPv6 Fast Handovers". |
|
| |
| RFC 7412 | Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection |
| |
| Authors: | Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7412 |
|
This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLSTransport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP)Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. |
|
| |
| RFC 7413 | TCP Fast Open |
| |
| Authors: | Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7413 |
|
This document describes an experimental TCP mechanism called TCP FastOpen (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake(3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. |
|
| |
| RFC 7414 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. |
| Date: | February 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 4614 |
| Updated by: | RFC 7805 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7414 |
|
This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.
This document obsoletes RFC 4614. |
|
| |
| RFC 7415 | Session Initiation Protocol (SIP) Rate Control |
| |
| Authors: | E. Noel, P. Williams. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7415 |
|
The prevalent use of the Session Initiation Protocol (SIP) in NextGeneration Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme. |
|
| |
| RFC 7416 | A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) |
| |
| Authors: | T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed.. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7416 |
|
This document presents a security threat analysis for the RoutingProtocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. |
|
| |
| RFC 7417 | Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains |
| |
| Authors: | G. Karagiannis, A. Bhargava. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7417 |
|
This document specifies extensions to Generic Aggregate RSVP (RFC4860) for support of the Pre-Congestion Notification (PCN) ControlledLoad (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN. |
|
| |
| RFC 7418 | An IRTF Primer for IETF Participants |
| |
| Authors: | S. Dawkins, Ed.. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7418 |
|
This document provides a high-level description of things forInternet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the InternetResearch Task Force (IRTF). This document emphasizes differences in expectations between the two organizations. |
|
| |
| RFC 7419 | Common Interval Support in Bidirectional Forwarding Detection |
| |
| Authors: | N. Akiya, M. Binderberger, G. Mirsky. |
| Date: | December 2014 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7419 |
|
Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to runBFD sessions.
This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals. |
|
| |
| RFC 7420 | Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module |
| |
| Authors: | A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7420 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling of the PathComputation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path ComputationElement (PCE), or between two PCEs. |
|
| |
| RFC 7421 | Analysis of the 64-bit Boundary in IPv6 Addressing |
| |
| Authors: | B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7421 |
|
The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet.Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary. |
|
| |
| RFC 7422 | Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments |
| |
| Authors: | C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7422 |
|
In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response).Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges.Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use. |
|
| |
| RFC 7423 | Diameter Applications Design Guidelines |
| |
| Authors: | L. Morand, Ed., V. Fajardo, H. Tschofenig. |
| Date: | November 2014 |
| Formats: | txt html json |
| Also: | BCP 0193 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7423 |
|
The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions. |
|
| |
| RFC 7424 | Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks |
| |
| Authors: | R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7424 |
|
Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this. |
|
| |
| RFC 7425 | Adobe's RTMFP Profile for Flash Communication |
| |
| Authors: | M. Thornburgh. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7425 |
|
This memo describes how to use Adobe's Secure Real-Time Media FlowProtocol (RTMFP) to transport the video, audio, and data messages ofAdobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. |
|
| |
| RFC 7426 | Software-Defined Networking (SDN): Layers and Architecture Terminology |
| |
| Authors: | E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7426 |
|
Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking ResearchGroup (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer- reviewed literature, the RFC series, and relevant documents by other standards organizations. |
|
| |
| RFC 7427 | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
|
The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA).The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited toECDSA; it can also be used with other signature algorithms. |
|
| |
| RFC 7428 | Transmission of IPv6 Packets over ITU-T G.9959 Networks |
| |
| Authors: | A. Brandt, J. Buron. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7428 |
|
This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. |
|
| |
| RFC 7429 | Distributed Mobility Management: Current Practices and Gap Analysis |
| |
| Authors: | D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7429 |
|
This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. |
|
| |
| RFC 7430 | Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) |
| |
| Authors: | M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7430 |
|
This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them. |
|
| |
| RFC 7431 | Multicast-Only Fast Reroute |
| |
| Authors: | A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7431 |
|
As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services.This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only FastReroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) andMultipoint LDP (mLDP). |
|
| |
| RFC 7432 | BGP MPLS-Based Ethernet VPN |
| |
| Authors: | A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. |
| Date: | February 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8584, RFC 9161, RFC 9572, RFC 9573 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7432 |
|
This document describes procedures for BGP MPLS-based Ethernet VPNs(EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". |
|
| |
| RFC 7433 | A Mechanism for Transporting User-to-User Call Control Information in SIP |
| |
| Authors: | A. Johnston, J. Rafferty. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7433 |
|
There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. |
|
| |
| RFC 7434 | Interworking ISDN Call Control User Information with SIP |
| |
| Authors: | K. Drage, Ed., A. Johnston. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7434 |
|
The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital SubscriberSignalling System No. 1 (DSS1) User-user information element withinSIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of theUser-to-User header field to enable interworking with this ISDN service.
This document covers interworking with both public ISDN and privateISDN capabilities, so the potential interworking with QSIG will also be addressed.
The package is identified by the new value "isdn-uui" of the"purpose" header field parameter. |
|
| |
| RFC 7435 | Opportunistic Security: Some Protection Most of the Time |
| |
| Authors: | V. Dukhovni. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7435 |
|
This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based onOpportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. |
|
| |
| RFC 7436 | IP-Only LAN Service (IPLS) |
| |
| Authors: | H. Shah, E. Rosen, F. Le Faucheur, G. Heron. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 7436 |
|
A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LANService" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destinationMedia Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via theMAC address learning procedures specified in the IEEE's "Media AccessControl (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.
The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learningMAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as EthernetVPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas. |
|
| |
| RFC 7437 | IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published. |
|
| |
| RFC 7438 | Multipoint LDP (mLDP) In-Band Signaling with Wildcards |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. |
| Date: | January 2015 |
| Formats: | txt json html |
| Updates: | RFC 6826, RFC 7246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7438 |
|
There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label SwitchedPath (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or BidirectionalMulticast trees) to be attached to an MPLS Multipoint Label SwitchedPath (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP-LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IPAny-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246. |
|
| |
| RFC 7439 | Gap Analysis for Operating IPv6-Only MPLS Networks |
| |
| Authors: | W. George, Ed., C. Pignataro, Ed.. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7439 |
|
This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations(or lack thereof) in the context of IPv6-only MPLS functionality.
In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations.However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols. |
|
| |
| RFC 7440 | TFTP Windowsize Option |
| |
| Authors: | P. Masotta. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7440 |
|
The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.
This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension"(RFC 2347). |
|
| |
| RFC 7441 | Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes |
| |
| Authors: | IJ. Wijnands, E. Rosen, U. Joorde. |
| Date: | January 2015 |
| Formats: | txt html json |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7441 |
|
Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in theirVPNs. It is also desirable to be able to support customers who haveMPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514. |
|
| |
| RFC 7442 | Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) |
| |
| Authors: | Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7442 |
|
When IP multicast trees created by Protocol Independent Multicast -Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees toPoint-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions forP2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP). |
|
| |
| RFC 7443 | Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages |
| |
| Authors: | P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7443 |
|
Application-Layer Protocol Negotiation (ALPN) labels for SessionTraversal Utilities for NAT (STUN) usages, such as Traversal UsingRelays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and DatagramTransport Layer Security (DTLS). |
|
| |
| RFC 7444 | Security Labels in Internet Email |
| |
| Authors: | K. Zeilenga, A. Melnikov. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7444 |
|
This document describes a header field, SIO-Label, for use inInternet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label. |
|
| |
| RFC 7445 | Analysis of Failure Cases in IPv6 Roaming Scenarios |
| |
| Authors: | G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7445 |
|
This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios.The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. |
|
| |
| RFC 7446 | Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7446 |
|
This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength SwitchedOptical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing aGMPLS control plane are discussed. |
|
| |
| RFC 7447 | Deprecation of BGP Entropy Label Capability Attribute |
| |
| Authors: | J. Scudder, K. Kompella. |
| Date: | February 2015 |
| Formats: | txt json html |
| Updates: | RFC 6790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7447 |
|
The BGP Entropy Label Capability attribute is defined in RFC 6790.Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice.This specification deprecates the attribute. A forthcoming document will propose a replacement. |
|
| |
| RFC 7448 | MIB Transfer from the IETF to the IEEE 802.3 WG |
| |
| Authors: | T. Taylor, Ed., D. Romascanu. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7448 |
|
This document records the transfer of responsibility for theEthernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB,POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB,ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group(WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG. |
|
| |
| RFC 7449 | Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7449 |
|
This memo provides application-specific requirements for the PathComputation Element Communication Protocol (PCEP) for the support ofWavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process.From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. |
|
| |
| RFC 7450 | Automatic Multicast Tunneling |
| |
|
|
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. |
|
| |
| RFC 7451 | Extension Registry for the Extensible Provisioning Protocol |
| |
| Authors: | S. Hollenbeck. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7451 |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. |
|
| |
| RFC 7452 | Architectural Considerations in Smart Object Networking |
| |
| Authors: | H. Tschofenig, J. Arkko, D. Thaler, D. McPherson. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7452 |
|
The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered byInternet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment.Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.
This document offers guidance to engineers designing Internet- connected smart objects. |
|
| |
| RFC 7453 | MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) |
| |
| Authors: | V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7453 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. |
|
| |
| RFC 7454 | BGP Operations and Security |
| |
| Authors: | J. Durand, I. Pepelnjak, G. Doering. |
| Date: | February 2015 |
| Formats: | txt html json |
| Also: | BCP 0194 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7454 |
|
The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.
This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System(AS) path filtering, route flap dampening, and BGP community scrubbing. |
|
| |
| RFC 7455 | Transparent Interconnection of Lots of Links (TRILL): Fault Management |
| |
| Authors: | T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li. |
| Date: | March 2015 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7455 |
|
This document specifies Transparent Interconnection of Lots of Links(TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (ConnectivityFault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL- specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1.This document updates RFC 6325. |
|
| |
| RFC 7456 | Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7456 |
|
Performance Monitoring (PM) is a key aspect of Operations,Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms forLoss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks. |
|
| |
| RFC 7457 | Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) |
| |
| Authors: | Y. Sheffer, R. Holz, P. Saint-Andre. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7457 |
|
Over the last few years, there have been several serious attacks onTransport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DatagramTLS (DTLS). |
|
| |
| RFC 7458 | Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core |
| |
| Authors: | R. Valmikam, R. Koodli. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7458 |
|
With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well.Such functions include Access Point Name (APN) Selection, multiplePacket Data Network (PDN) connections, and seamless mobility betweenWi-Fi and 3G/4G networks.
The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile EvolvedPacket Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as aMobile Node (MN)) and its network counterpart (such as anAuthentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure. |
|
| |
| RFC 7459 | Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) |
| |
|
|
This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.
This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693. |
|
| |
| RFC 7460 | Monitoring and Control MIB for Power and Energy |
| |
| Authors: | M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7460 |
|
This document defines a subset of the Management Information Base(MIB) for power and energy monitoring of devices. |
|
| |
| RFC 7461 | Energy Object Context MIB |
| |
| Authors: | J. Parello, B. Claise, M. Chandramouli. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7461 |
|
This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices. |
|
| |
| RFC 7462 | URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) |
| |
| Authors: | L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat. |
| Date: | March 2015 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7462 |
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UserAgent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
This document normatively updates RFC 3261, which defines the SessionInitiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values. |
|
| |
| RFC 7463 | Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) |
| |
| Authors: | A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan. |
| Date: | March 2015 |
| Formats: | txt json html |
| Updates: | RFC 3261, RFC 4235 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7463 |
|
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance(BLA) or Multiple Line Appearance (MLA), or Shared Call/LineAppearance (SCA). When implemented using the Session InitiationProtocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP PrivateBranch Exchange (IPBX) offerings and is likely to be implemented onSIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and4235. |
|
| |
| RFC 7464 | JavaScript Object Notation (JSON) Text Sequences |
| |
| Authors: | N. Williams. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7464 |
|
This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". AJSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A). |
|
| |
| RFC 7465 | Prohibiting RC4 Cipher Suites |
| |
|
|
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. |
|
| |
| RFC 7466 | An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
|
|
The link quality mechanism of the Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.
NHDP also collects information about symmetric 2-hop neighbors.However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed.This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.
This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The OptimizedLink State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more"robust". |
|
| |
| RFC 7467 | URN Namespace for the North Atlantic Treaty Organization (NATO) |
| |
| Authors: | A. Murdock. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7467 |
|
This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization(NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications. |
|
| |
| RFC 7468 | Textual Encodings of PKIX, PKCS, and CMS Structures |
| |
| Authors: | S. Josefsson, S. Leonard. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7468 |
|
This document describes and discusses the textual encodings of thePublic-Key Infrastructure X.509 (PKIX), Public-Key CryptographyStandards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. |
|
| |
| RFC 7469 | Public Key Pinning Extension for HTTP |
| |
| Authors: | C. Evans, C. Palmer, R. Sleevi. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7469 |
|
This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromisedCertification Authorities. |
|
| |
| RFC 7470 | Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.
This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object. |
|
| |
| RFC 7471 | OSPF Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7471 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.
This document describes common extensions to RFC 3630 "TrafficEngineering (TE) Extensions to OSPF Version 2" and RFC 5329 "TrafficEngineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.
Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. |
|
| |
| RFC 7472 | Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme |
| |
|
|
This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.
This document updates RFCs 2910 and 2911. |
|
| |
| RFC 7473 | Controlling State Advertisements of Non-negotiated LDP Applications |
| |
|
|
There is no capability negotiation done for Label DistributionProtocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session. |
|
| |
| RFC 7474 | Security Extension for OSPFv2 When Using Manual Key Management |
| |
|
|
The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.
This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header. |
|
| |
| RFC 7475 | Increasing the Number of Area Directors in an IETF Area |
| |
|
|
This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25). |
|
| |
| RFC 7476 | Information-Centric Networking: Baseline Scenarios |
| |
| Authors: | K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7476 |
|
This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 7477 | Child-to-Parent Synchronization in DNS |
| |
| Authors: | W. Hardaker. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7477 |
|
This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. |
|
| |
| RFC 7478 | Web Real-Time Communication Use Cases and Requirements |
| |
| Authors: | C. Holmberg, S. Hakansson, G. Eriksson. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7478 |
|
This document describes web-based real-time communication use cases.Requirements on the browser functionality are derived from the use cases.
This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. |
|
| |
| RFC 7479 | Using Ed25519 in SSHFP Resource Records |
| |
| Authors: | S. Moonesamy. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7479 |
|
The Ed25519 signature algorithm has been implemented in OpenSSH.This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. |
|
| |
| RFC 7480 | HTTP Usage in the Registration Data Access Protocol (RDAP) |
| |
| Authors: | A. Newton, B. Ellacott, N. Kong. |
| Date: | March 2015 |
| Formats: | txt html json |
| Also: | STD 0095 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 7480 |
|
This document is one of a collection that together describes theRegistration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. |
|
| |
| RFC 7481 | Security Services for the Registration Data Access Protocol (RDAP) |
| |
|
|
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name andRegional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. |
|
| |
| RFC 7482 | Registration Data Access Protocol (RDAP) Query Format |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9082 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7482 |
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP). |
|
| |
| RFC 7483 | JSON Responses for the Registration Data Access Protocol (RDAP) |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9083 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7483 |
|
This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. |
|
| |
| RFC 7484 | Finding the Authoritative Registration Data (RDAP) Service |
| |
|
|
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers. |
|
| |
| RFC 7485 | Inventory and Analysis of WHOIS Registration Objects |
| |
| Authors: | L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7485 |
|
WHOIS output objects from registries, including both RegionalInternet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information.The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration DataAccess Protocol (RDAP) responses. |
|
| |
| RFC 7486 | HTTP Origin-Bound Authentication (HOBA) |
| |
| Authors: | S. Farrell, P. Hoffman, M. Thomas. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7486 |
|
HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. |
|
| |
| RFC 7487 | Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE |
| |
| Authors: | E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7487 |
|
This specification describes the configuration of proactive MPLSTransport Profile (MPLS-TP) Operations, Administration, andMaintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE. |
|
| |
| RFC 7488 | Port Control Protocol (PCP) Server Selection |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy. |
| Date: | March 2015 |
| Formats: | txt html json |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7488 |
|
This document specifies the behavior to be followed by a Port ControlProtocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.
This document updates RFC 6887. |
|
| |
| RFC 7489 | Domain-based Message Authentication, Reporting, and Conformance (DMARC) |
| |
|
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.
Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits:Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.
DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. |
|
| |
| RFC 7490 | Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) |
| |
| Authors: | S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7490 |
|
This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms. |
|
| |
| RFC 7491 | A PCE-Based Architecture for Application-Based Network Operations |
| |
| Authors: | D. King, A. Farrel. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7491 |
|
Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations(ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.
This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. |
|
| |
| RFC 7492 | Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines |
| |
| Authors: | M. Bhatia, D. Zhang, M. Jethanandani. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7492 |
|
This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC6518, "Keying and Authentication for Routing Protocols (KARP) DesignGuidelines". |
|
| |
| RFC 7493 | The I-JSON Message Format |
| |
| Authors: | T. Bray, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7493 |
|
I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. |
|
| |
| RFC 7494 | IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7494 |
|
The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control(MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs):Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the SplitMAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP andAC. |
|
| |
| RFC 7495 | Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) |
| |
| Authors: | A. Montville, D. Black. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7495 |
|
The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEFReference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.
This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not updateIODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references. |
|
| |
| RFC 7496 | Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension |
| |
| Authors: | M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7496 |
|
This document defines two additional policies for the PartiallyReliable Stream Control Transmission Protocol (PR-SCTP) extension.These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer. |
|
| |
| RFC 7497 | Rate Measurement Test Protocol Problem Statement and Requirements |
| |
| Authors: | A. Morton. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7497 |
|
This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. |
|
| |
| RFC 7498 | Problem Statement for Service Function Chaining |
| |
| Authors: | P. Quinn, Ed., T. Nadeau, Ed.. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7498 |
|
This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.
The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.
This document also identifies several key areas that the ServiceFunction Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents. |
|
| |
| RFC 7499 | Support of Fragmentation of RADIUS Packets |
| |
| Authors: | A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7499 |
|
The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers. |
|
