| |
| RFC 7100 | Retirement of the "Internet Official Protocol Standards" Summary Document |
| |
|
|
This document updates RFC 2026 to no longer use STD 1 as a summary of"Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status. |
|
| |
| RFC 7101 | List of Internet Official Protocol Standards: Replaced by a Web Page |
| |
| Authors: | S. Ginoza. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7101 |
|
At one time, the RFC Editor published snapshots of the "InternetOfficial Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFCEditor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment. |
|
| |
| RFC 7102 | Terms Used in Routing for Low-Power and Lossy Networks |
| |
| Authors: | JP. Vasseur. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7102 |
|
This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power andLossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. |
|
| |
| RFC 7103 | Advice for Safe Handling of Malformed Messages |
| |
| Authors: | M. Kucherawy, G. Shapiro, N. Freed. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7103 |
|
Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance. |
|
| |
| RFC 7104 | Duplication Grouping Semantics in the Session Description Protocol |
| |
| Authors: | A. Begen, Y. Cai, H. Ou. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7104 |
|
Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP).The semantics defined in this document are to be used with the SDPGrouping Framework. Grouping semantics at the Synchronization Source(SSRC) level are also defined in this document for RTP streams usingSSRC multiplexing. |
|
| |
| RFC 7105 | Using Device-Provided Location-Related Measurements in Location Configuration Protocols |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7105 |
|
This document describes a protocol for a Device to provide location- related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global NavigationSatellite System (GNSS) parameters. |
|
| |
| RFC 7106 | A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State |
| |
| Authors: | E. Ivov. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7106 |
|
This document defines and registers a value of "grouptextchat"("Group Text Chat") for the URI <purpose&rt; element of SIP's ConferenceEvent Package. |
|
| |
| RFC 7107 | Object Identifier Registry for the S/MIME Mail Security Working Group |
| |
| Authors: | R. Housley. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7107 |
|
When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc toIANA, and establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7108 | A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes |
| |
| Authors: | J. Abley, T. Manderson. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7108 |
|
Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.
Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed.Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.
This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service. |
|
| |
| RFC 7109 | Flow Bindings Initiated by Home Agents for Mobile IPv6 |
| |
| Authors: | H. Yokota, D. Kim, B. Sarikaya, F. Xia. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7109 |
|
There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6. |
|
| |
| RFC 7110 | Return Path Specified Label Switched Path (LSP) Ping |
| |
| Authors: | M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7110 |
|
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. |
|
| |
| RFC 7111 | URI Fragment Identifiers for the text/csv Media Type |
| |
| Authors: | M. Hausenblas, E. Wilde, J. Tennison. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updates: | RFC 4180 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7111 |
|
This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell.Fragment identification can use single items or ranges. |
|
| |
| RFC 7112 | Implications of Oversized IPv6 Header Chains |
| |
| Authors: | F. Gont, V. Manral, R. Bonica. |
| Date: | January 2014 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7112 |
|
The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that theFirst Fragment of a packet is required to contain the entire IPv6Header Chain. |
|
| |
| RFC 7113 | Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) |
| |
|
|
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 RouterAdvertisement messages. Many existing IPv6 deployments rely onRA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 ExtensionHeaders. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. |
|
| |
| RFC 7114 | Creation of a Registry for smime-type Parameter Values |
| |
| Authors: | B. Leiba. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7114 |
|
Secure/Multipurpose Internet Mail Extensions (S/MIME) defined theContent-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values. |
|
| |
| RFC 7115 | Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) |
| |
|
|
Deployment of BGP origin validation that is based on the ResourcePublic Key Infrastructure (RPKI) has many operational considerations.This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. |
|
| |
| RFC 7116 | Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries |
| |
| Authors: | K. Scott, M. Blanchet. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7116 |
|
The DTNRG Research Group has defined the experimental LickliderTransmission Protocol (LTP) and the Compressed Bundle Header Encoding(CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions. |
|
| |
| RFC 7117 | Multicast in Virtual Private LAN Service (VPLS) |
| |
| Authors: | R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7117 |
|
RFCs 4761 and 4762 describe a solution for Virtual Private LANService (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certainVPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.
This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multipleVPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. |
|
| |
| RFC 7118 | The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) |
| |
| Authors: | I. Baz Castillo, J. Millan Villegas, V. Pascual. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7118 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use ofSIP in web-oriented deployments. |
|
| |
| RFC 7119 | Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators |
| |
| Authors: | B. Claise, A. Kobayashi, B. Trammell. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7119 |
|
This document specifies the operation of the IP Flow InformationExport (IPFIX) protocol specific to IPFIX Mediators, includingTemplate and Observation Point management, timing considerations, and other Mediator-specific concerns. |
|
| |
| RFC 7120 | Early IANA Allocation of Standards Track Code Points |
| |
|
|
This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFCRequired", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.
This document obsoletes RFC 4020. |
|
| |
| RFC 7121 | High Availability within a Forwarding and Control Element Separation (ForCES) Network Element |
| |
| Authors: | K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. |
| Date: | February 2014 |
| Formats: | txt html json |
| Updates: | RFC 5810 |
| Updated by: | RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7121 |
|
This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) NetworkElement (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism. |
|
| |
| RFC 7122 | Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) |
| |
| Authors: | H. Kruse, S. Jero, S. Ostermann. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7122 |
|
This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over theInternet using datagrams. It covers convergence layers for theBundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of theDelay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. |
|
| |
| RFC 7123 | Security Implications of IPv6 on IPv4 Networks |
| |
| Authors: | F. Gont, W. Liu. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7123 |
|
This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues. |
|
| |
| RFC 7124 | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
|
This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of theEFM-CU-MIB module from the concluded IETF Ethernet Interfaces and HubMIB Working Group to the Institute of Electrical and ElectronicsEngineers (IEEE) 802.3 working group. |
|
| |
| RFC 7125 | Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element |
| |
| Authors: | B. Trammell, P. Aitken. |
| Date: | February 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9565 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7125 |
|
This document revises the tcpControlBits IP Flow Information Export(IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. |
|
| |
| RFC 7126 | Recommendations on Filtering of IPv4 Packets Containing IPv4 Options |
| |
| Authors: | F. Gont, R. Atkinson, C. Pignataro. |
| Date: | February 2014 |
| Formats: | txt json html |
| Also: | BCP 0186 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7126 |
|
This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. |
|
| |
| RFC 7127 | Characterization of Proposed Standards |
| |
|
|
RFC 2026 describes the review performed by the Internet EngineeringSteering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards. |
|
| |
| RFC 7128 | Resource Public Key Infrastructure (RPKI) Router Implementation Report |
| |
| Authors: | R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7128 |
|
This document is an implementation report for the Resource Public KeyInfrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab. |
|
| |
| RFC 7129 | Authenticated Denial of Existence in the DNS |
| |
| Authors: | R. Gieben, W. Mekking. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7129 |
|
Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record(RR) type you were asking for. When returning a negative DNSSecurity Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.
This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses. |
|
| |
| RFC 7130 | Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces |
| |
| Authors: | M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed.. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7130 |
|
This document defines a mechanism to run Bidirectional ForwardingDetection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on everyLAG member link.
This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link AggregationControl Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements ofLayer 3 (L3) bidirectional forwarding. |
|
| |
| RFC 7131 | Session Initiation Protocol (SIP) History-Info Header Call Flow Examples |
| |
| Authors: | M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7131 |
|
This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. |
|
| |
| RFC 7132 | Threat Model for BGP Path Security |
| |
| Authors: | S. Kent, A. Chi. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7132 |
|
This document describes a threat model for the context in whichExternal Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the ResourcePublic Key Infrastructure (RPKI) and focuses on the ability of anAutonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to anyBGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of theRPKI.
The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in theBGP-4 standard. It concludes with a brief discussion of residual vulnerabilities. |
|
| |
| RFC 7133 | Information Elements for Data Link Layer Traffic Measurement |
| |
| Authors: | S. Kashima, A. Kobayashi, Ed., P. Aitken. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7133 |
|
This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. |
|
| |
| RFC 7134 | The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" |
| |
|
|
RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updatesRFC 4412 to change the management policy of these registries to "IETFReview". |
|
| |
| RFC 7135 | Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications |
| |
| Authors: | J. Polk. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7135 |
|
This document creates the new Session Initiation Protocol (SIP)Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point(PSAP), between PSAPs, and between a PSAP and first responders and their organizations. |
|
| |
| RFC 7136 | Significance of IPv6 Interface Identifiers |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | February 2014 |
| Formats: | txt json html |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7136 |
|
The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses.Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which theUniversal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updatesRFC 4291 accordingly. |
|
| |
| RFC 7137 | Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks |
| |
|
|
This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.
This document updates RFC 5820. |
|
| |
| RFC 7138 | Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks |
| |
| Authors: | D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7138 |
|
This document describes Open Shortest Path First - TrafficEngineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-TRecommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203. |
|
| |
| RFC 7139 | GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks |
| |
| Authors: | F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. |
| Date: | March 2014 |
| Formats: | txt html json |
| Updates: | RFC 4328 |
| Updated by: | RFC 7892 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7139 |
|
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channelData Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.
This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. |
|
| |
| RFC 7140 | LDP Extensions for Hub and Spoke Multipoint Label Switched Path |
| |
| Authors: | L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. |
| Date: | March 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7140 |
|
This document introduces a hub and spoke multipoint (HSMP) LabelSwitched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed. |
|
| |
| RFC 7141 | Byte and Packet Congestion Notification |
| |
|
|
This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre-Congestion Notification (PCN), and newer schemes such as CoDel(Controlled Delay) and PIE (Proportional Integral controllerEnhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. |
|
| |
| RFC 7142 | Reclassification of RFC 1142 to Historic |
| |
|
|
This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain RoutingProtocol", to Historic status. This memo also obsoletes RFC 1142. |
|
| |
| RFC 7143 | Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) |
| |
|
|
This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.
This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. |
|
| |
| RFC 7144 | Internet Small Computer System Interface (iSCSI) SCSI Features Update |
| |
| Authors: | F. Knight, M. Chadalapaka. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7144 |
|
Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols ontoTCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined inSAM-3, SAM-4, and SAM-5.
This document is a companion document to RFC 7143. |
|
| |
| RFC 7145 | Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification |
| |
|
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/OBuffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.
This document obsoletes RFC 5046. |
|
| |
| RFC 7146 | Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 |
| |
| Authors: | D. Black, P. Koning. |
| Date: | April 2014 |
| Formats: | txt html json |
| Updates: | RFC 3720, RFC 3723, RFC 3821, RFC 3822, RFC 4018, RFC 4172, RFC 4173, RFC 4174, RFC 5040, RFC 5041, RFC 5042, RFC 5043, RFC 5044, RFC 5045, RFC 5046, RFC 5047, RFC 5048 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7146 |
|
RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP).This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published. |
|
| |
| RFC 7147 | Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Bakke, P. Venkatesen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4544 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7147 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet SmallComputer System Interface (iSCSI) protocol (SCSI over TCP).
This document obsoletes RFC 4544. |
|
| |
| RFC 7148 | Prefix Delegation Support for Proxy Mobile IPv6 |
| |
| Authors: | X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7148 |
|
This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. |
|
| |
| RFC 7149 | Software-Defined Networking: A Perspective from within a Service Provider Environment |
| |
| Authors: | M. Boucadair, C. Jacquenet. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7149 |
|
Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.
It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. |
|
| |
| RFC 7150 | Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol |
| |
| Authors: | F. Zhang, A. Farrel. |
| Date: | March 2014 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7470 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7150 |
|
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-Variable that can be carried in any existing PCEP object. |
|
| |
| RFC 7151 | File Transfer Protocol HOST Command for Virtual Hosts |
| |
|
|
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. |
|
| |
| RFC 7152 | Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) |
| |
| Authors: | R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7152 |
|
This document provides functional requirements for the support ofMetro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer2 Virtual Private Network solutions (referred to as simply "L2VPN").It is intended that potential solutions will use these requirements as guidelines. |
|
| |
| RFC 7153 | IANA Registries for BGP Extended Communities |
| |
|
|
This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the"IANA Considerations" sections of future protocol specifications.This document updates RFC 4360 and RFC 5701. |
|
| |
| RFC 7154 | IETF Guidelines for Conduct |
| |
|
|
This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.
This document is an updated version of the guidelines for conduct originally published in RFC 3184. |
|
| |
| RFC 7155 | Diameter Network Access Server Application |
| |
|
|
This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting services in the NetworkAccess Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, andExtensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. |
|
| |
| RFC 7156 | Diameter Support for Proxy Mobile IPv6 Localized Routing |
| |
| Authors: | G. Zorn, Q. Wu, J. Korhonen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7156 |
|
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by theMobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term"localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node(CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. |
|
| |
| RFC 7157 | IPv6 Multihoming without Network Address Translation |
| |
| Authors: | O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7157 |
|
Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because anIPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. ForIPv6 hosts, one approach could be the use of IPv6-to-IPv6 NetworkPrefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution. |
|
| |
| RFC 7158 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7159 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7160 | Support for Multiple Clock Rates in an RTP Session |
| |
| Authors: | M. Petit-Huguenin, G. Zorn, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7160 |
|
This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550. |
|
| |
| RFC 7161 | Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) |
| |
| Authors: | LM. Contreras, CJ. Bernardos, I. Soto. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7161 |
|
This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router). |
|
| |
| RFC 7162 | IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) |
| |
|
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.
Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state.This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.
This document additionally updates another IMAP extension, QuickResynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.
Finally, this document also updates the line-length recommendation inSection 3.2.1.5 of RFC 2683. |
|
| |
| RFC 7163 | URN for Country-Specific Emergency Services |
| |
| Authors: | C. Holmberg, I. Sedlacek. |
| Date: | March 2014 |
| Formats: | txt html json |
| Updates: | RFC 5031 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7163 |
|
This document updates the registration guidance provided in Section4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country. |
|
| |
| RFC 7164 | RTP and Leap Seconds |
| |
| Authors: | K. Gross, R. Brandenburg. |
| Date: | March 2014 |
| Formats: | txt json html |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7164 |
|
This document discusses issues that arise when RTP sessions spanCoordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds. |
|
| |
| RFC 7165 | Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | R. Barnes. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7165 |
|
Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax(CMS) has provided a binary secure object format based on ASN.1.Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript ObjectNotation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development. |
|
| |
| RFC 7166 | Supporting Authentication Trailer for OSPFv3 |
| |
| Authors: | M. Bhatia, V. Manral, A. Lindem. |
| Date: | March 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6506 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7166 |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.
The OSPFv3 Authentication Trailer was originally defined in RFC 6506.This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. |
|
| |
| RFC 7167 | A Framework for Point-to-Multipoint MPLS in Transport Networks |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci, L. Berger. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7167 |
|
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths.This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to- multipoint transport paths. |
|
| |
| RFC 7168 | The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) |
| |
|
|
The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities. |
|
| |
| RFC 7169 | The NSA (No Secrecy Afforded) Certificate Extension |
| |
| Authors: | S. Turner. |
| Date: | 1 April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7169 |
|
This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic KeyCertificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party.Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party. |
|
| |
| RFC 7170 | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
| Authors: | H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9427 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7170 |
|
This document defines the Tunnel Extensible Authentication Protocol(TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using theTransport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. |
|
| |
| RFC 7171 | PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods |
| |
| Authors: | N. Cam-Winget, P. Sangster. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7171 |
|
This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport LayerSecurity (TLS). The document also describes the intended applicability of PT-EAP. |
|
| |
| RFC 7172 | Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling |
| |
| Authors: | D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7172 |
|
The IETF has standardized Transparent Interconnection of Lots ofLinks (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4KIDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine- grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other. |
|
| |
| RFC 7173 | Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires |
| |
| Authors: | L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7173 |
|
This document specifies how to interconnect a pair of TransparentInterconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End(PWE3) standards. |
|
| |
| RFC 7174 | Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework |
| |
| Authors: | S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7174 |
|
This document specifies a reference framework for Operations,Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM. |
|
| |
| RFC 7175 | Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support |
| |
| Authors: | V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7175 |
|
This document specifies use of the Bidirectional Forwarding Detection(BFD) protocol in Routing Bridge (RBridge) campuses based on theRBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.
BFD is a widely deployed Operations, Administration, and Maintenance(OAM) mechanism in IP and MPLS networks, using UDP and AssociatedChannel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL. |
|
| |
| RFC 7176 | Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS |
| |
| Authors: | D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee. |
| Date: | May 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6326 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7176 |
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other thanTRILL. This document obsoletes RFC 6326. |
|
| |
| RFC 7177 | Transparent Interconnection of Lots of Links (TRILL): Adjacency |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network(LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System(IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325. |
|
| |
| RFC 7178 | Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support |
| |
| Authors: | D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7978 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7178 |
|
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the TransparentInterconnection of Lots of Links (TRILL) protocol. |
|
| |
| RFC 7179 | Transparent Interconnection of Lots of Links (TRILL): Header Extension |
| |
| Authors: | D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updates: | RFC 6325 |
| Updated by: | RFC 7780 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7179 |
|
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILLHeader extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325. |
|
| |
| RFC 7180 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic.TRILL accomplishes this by using Intermediate System to IntermediateSystem (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439. |
|
| |
| RFC 7181 | The Optimized Link State Routing Protocol Version 2 |
| |
|
|
This specification describes version 2 of the Optimized Link StateRouting Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs). |
|
| |
| RFC 7182 | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | U. Herberg, T. Clausen, C. Dearlove. |
| Date: | April 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7182 |
|
This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic IntegrityCheck Values (ICVs) and timestamps, using the generalized Mobile AdHoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. |
|
| |
| RFC 7183 | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This document specifies integrity and replay protection for theMobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2).This protection is achieved by using an HMAC-SHA-256 Integrity CheckValue (ICV) TLV and a Timestamp TLV based on Portable OperatingSystem Interface (POSIX) time.
The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described inRFC 5444.
This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP andOLSRv2. |
|
| |
| RFC 7184 | Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 |
| |
| Authors: | U. Herberg, R. Cole, T. Clausen. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7184 |
|
This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State RoutingProtocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers. |
|
| |
| RFC 7185 | Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale |
| |
| Authors: | C. Dearlove, T. Clausen, P. Jacquet. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7185 |
|
The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. |
|
| |
| RFC 7186 | Security Threats for the Neighborhood Discovery Protocol (NHDP) |
| |
| Authors: | J. Yi, U. Herberg, T. Clausen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7985 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7186 |
|
This document analyzes common security threats of the NeighborhoodDiscovery Protocol (NHDP) and describes their potential impacts onMobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described. |
|
| |
| RFC 7187 | Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization. |
|
| |
| RFC 7188 | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs |
| |
|
|
This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updatesRFC 7181 (OLSRv2) and RFC 6130 (NHDP). |
|
| |
| RFC 7189 | Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | G. Mirsky. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7189 |
|
This document specifies how signaling and selection processes forPseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactiveConnectivity Verification (CV), Continuity Check (CC), and RemoteDefect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs.This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined. |
|
| |
| RFC 7190 | Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | C. Villamizar. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7190 |
|
Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TPOperations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.
Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths(LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP.The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. |
|
| |
| RFC 7191 | Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
| Authors: | R. Housley. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7191 |
|
This document defines the syntax for two Cryptographic Message Syntax(CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types. |
|
| |
| RFC 7192 | Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
| Authors: | S. Turner. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7192 |
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData. |
|
| |
| RFC 7193 | The application/cms Media Type |
| |
| Authors: | S. Turner, R. Housley, J. Schaad. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7193 |
|
This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types. |
|
| |
| RFC 7194 | Default Port for Internet Relay Chat (IRC) via TLS/SSL |
| |
|
|
This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL. |
|
| |
| RFC 7195 | Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) |
| |
| Authors: | M. Garcia-Martin, S. Veikkolainen. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7195 |
|
This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). |
|
| |
| RFC 7196 | Making Route Flap Damping Usable |
| |
| Authors: | C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7196 |
|
Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process. |
|
| |
| RFC 7197 | Duplication Delay Attribute in the Session Description Protocol |
| |
| Authors: | A. Begen, Y. Cai, H. Ou. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7197 |
|
A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply"delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. |
|
| |
| RFC 7198 | Duplicating RTP Streams |
| |
| Authors: | A. Begen, C. Perkins. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7198 |
|
Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains howReal-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. |
|
| |
| RFC 7199 | Location Configuration Extensions for Policy Management |
| |
| Authors: | R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7199 |
|
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules. |
|
