| |
| RFC 6801 | Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework |
| |
| Authors: | U. Kozat, A. Begen. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6801 |
|
This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the SessionDescription Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. |
|
| |
| RFC 6802 | Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets |
| |
| Authors: | S. Baillargeon, C. Flinta, A. Johnsson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6802 |
|
This memo describes an extension to the Two-Way Active MeasurementProtocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. |
|
| |
| RFC 6803 | Camellia Encryption for Kerberos 5 |
| |
| Authors: | G. Hudson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6803 |
|
This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection. |
|
| |
| RFC 6804 | DISCOVER: Supporting Multicast DNS Queries |
| |
| Authors: | B. Manning. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6804 |
|
This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using theDISCOVER opcode and processes the multiple responses that may result. |
|
| |
| RFC 6805 | The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS |
| |
| Authors: | D. King, Ed., A. Farrel, Ed.. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6805 |
|
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path ComputationElement (PCE) architecture.
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. |
|
| |
| RFC 6806 | Kerberos Principal Name Canonicalization and Cross-Realm Referrals |
| |
| Authors: | S. Hartman, Ed., K. Raeburn, L. Zhu. |
| Date: | November 2012 |
| Formats: | txt json html |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6806 |
|
This memo documents a method for a Kerberos Key Distribution Center(KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realmTicket-Granting Ticket (TGT) to another realm on the referral path.The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. |
|
| |
| RFC 6807 | Population Count Extensions to Protocol Independent Multicast (PIM) |
| |
| Authors: | D. Farinacci, G. Shepherd, S. Venaas, Y. Cai. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6807 |
|
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the ProtocolIndependent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. |
|
| |
| RFC 6808 | Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track |
| |
| Authors: | L. Ciavattone, R. Geib, A. Morton, M. Wieser. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6808 |
|
This memo provides the supporting test plan and results to advanceRFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. |
|
| |
| RFC 6809 | Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Holmberg, I. Sedlacek, H. Kaplan. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6809 |
|
This specification defines a new SIP header field, Feature-Caps. TheFeature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier(URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-CapabilityIndicator Trees", for registering feature-capability indicators. |
|
| |
| RFC 6810 | The Resource Public Key Infrastructure (RPKI) to Router Protocol |
| |
| Authors: | R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6810 |
|
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. |
|
| |
| RFC 6811 | BGP Prefix Origin Validation |
| |
| Authors: | P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8481, RFC 8893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6811 |
|
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AutonomousSystem (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. |
|
| |
| RFC 6812 | Cisco Service-Level Assurance Protocol |
| |
| Authors: | M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6812 |
|
Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is aPerformance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. |
|
| |
| RFC 6813 | The Network Endpoint Assessment (NEA) Asokan Attack Analysis |
| |
| Authors: | J. Salowey, S. Hanna. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6813 |
|
The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA AsokanAttack. This document describes the attack and countermeasures that may be mounted. |
|
| |
| RFC 6814 | Formally Deprecating Some IPv4 Options |
| |
|
|
A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry.Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. |
|
| |
| RFC 6815 | Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful |
| |
| Authors: | S. Bradner, K. Dubray, J. McQuaid, A. Morton. |
| Date: | November 2012 |
| Formats: | txt html json |
| Updates: | RFC 2544 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6815 |
|
The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. |
|
| |
| RFC 6816 | Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME |
| |
| Authors: | V. Roca, M. Cunche, J. Lacan. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6816 |
|
This document describes a fully specified simple Forward ErrorCorrection (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. |
|
| |
| RFC 6817 | Low Extra Delay Background Transport (LEDBAT) |
| |
| Authors: | S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6817 |
|
Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. |
|
| |
| RFC 6818 | Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document updates RFC 5280, the "Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. |
|
| |
| RFC 6819 | OAuth 2.0 Threat Model and Security Considerations |
| |
| Authors: | T. Lodderstedt, Ed., M. McGloin, P. Hunt. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6819 |
|
This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. |
|
| |
| RFC 6820 | Address Resolution Problems in Large Data Center Networks |
| |
| Authors: | T. Narten, M. Karir, I. Foo. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6820 |
|
This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution(the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery(ND) in IPv6) within a data center. |
|
| |
| RFC 6821 | Improving Peer Selection in Peer-to-peer Applications: Myths vs |
| |
| Authors: | Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6821 |
|
Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.
This document is a product of the IRTF P2PRG (Peer-to-Peer ResearchGroup). |
|
| |
| RFC 6822 | IS-IS Multi-Instance |
| |
| Authors: | S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. |
| Date: | December 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8202 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6822 |
|
This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs. |
|
| |
| RFC 6823 | Advertising Generic Information in IS-IS |
| |
| Authors: | L. Ginsberg, S. Previdi, M. Shand. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6823 |
|
This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information. |
|
| |
| RFC 6824 | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8684 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6824 |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. |
|
| |
| RFC 6825 | Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS |
| |
| Authors: | M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6825 |
|
This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. |
|
| |
| RFC 6826 | Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| Authors: | IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. |
| Date: | January 2013 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6826 |
|
Consider an IP multicast tree, constructed by Protocol IndependentMulticast (PIM), that needs to pass through an MPLS domain in whichMultipoint LDP (mLDP) point-to-multipoint and/or multipoint-to- multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. |
|
| |
| RFC 6827 | Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols |
| |
| Authors: | A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed.. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 5787 |
| Updates: | RFC 5786 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6827 |
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH), Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. |
|
| |
| RFC 6828 | Content Splicing for RTP Sessions |
| |
| Authors: | J. Xia. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6828 |
|
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.
This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. |
|
| |
| RFC 6829 | Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 |
| |
|
|
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.
This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6LDP sessions. This document updates RFC 4379. |
|
| |
| RFC 6830 | The Locator/ID Separation Protocol (LISP) |
| |
|
|
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop. |
|
| |
| RFC 6831 | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
| Authors: | D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6831 |
|
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. |
|
| |
| RFC 6832 | Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites |
| |
| Authors: | D. Lewis, D. Meyer, D. Farinacci, V. Fuller. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6832 |
|
This document describes techniques for allowing sites running theLocator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 orIPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites.This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network AddressTranslation (NAT) functionality to LISP ITRs and LISP Egress TunnelRouters (ETRs) to substitute routable IP addresses for non-routableEIDs. Finally, this document introduces the Proxy Egress TunnelRouter (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. |
|
| |
| RFC 6833 | Locator/ID Separation Protocol (LISP) Map-Server Interface |
| |
| Authors: | V. Fuller, D. Farinacci. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9301 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6833 |
|
This document describes the Mapping Service for the Locator/IDSeparation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID toRouting Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress TunnelRouters are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs.Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. |
|
| |
| RFC 6834 | Locator/ID Separation Protocol (LISP) Map-Versioning |
| |
| Authors: | L. Iannone, D. Saucez, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9302 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6834 |
|
This document describes the LISP (Locator/ID Separation Protocol)Map-Versioning mechanism, which provides in-packet information aboutEndpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header ofLISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. |
|
| |
| RFC 6835 | The Locator/ID Separation Protocol Internet Groper (LIG) |
| |
| Authors: | D. Farinacci, D. Meyer. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6835 |
|
A simple tool called the Locator/ID Separation Protocol (LISP)Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. |
|
| |
| RFC 6836 | Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) |
| |
| Authors: | V. Fuller, D. Farinacci, D. Meyer, D. Lewis. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6836 |
|
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router(ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular EndpointIdentifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of RoutingLocators (RLOCs) for the EID. Termed the Alternative LogicalTopology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and GenericRouting Encapsulation (GRE). |
|
| |
| RFC 6837 | NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database |
| |
| Authors: | E. Lear. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6837 |
|
The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries. |
|
| |
| RFC 6838 | Media Type Specifications and Registration Procedures |
| |
|
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
|
| |
| RFC 6839 | Additional Media Type Structured Syntax Suffixes |
| |
|
|
A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json","+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. |
|
| |
| RFC 6840 | Clarifications and Implementation Notes for DNS Security (DNSSEC) |
| |
|
|
This document is a collection of technical clarifications to the DNSSecurity (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.
This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of theDNSSEC specification. |
|
| |
| RFC 6841 | A Framework for DNSSEC Policies and DNSSEC Practice Statements |
| |
| Authors: | F. Ljunggren, AM. Eklund Lowinder, T. Okubo. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6841 |
|
This document presents a framework to assist writers of DNS SecurityExtensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone withSecurity Extensions implemented.
In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. |
|
| |
| RFC 6842 | Client Identifier Option in DHCP Server Replies |
| |
| Authors: | N. Swamy, G. Halwasia, P. Jhingran. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updates: | RFC 2131 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6842 |
|
This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. |
|
| |
| RFC 6843 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting |
| |
| Authors: | A. Clark, K. Gross, Q. Wu. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6843 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. |
|
| |
| RFC 6844 | DNS Certification Authority Authorization (CAA) Resource Record |
| |
| Authors: | P. Hallam-Baker, R. Stradling. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8659 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6844 |
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain.CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. |
|
| |
| RFC 6845 | OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type |
| |
|
|
This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes ofOSPF operation. Neighbor discovery and maintenance as well as LinkState Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). |
|
| |
| RFC 6846 | RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) |
| |
| Authors: | G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 4996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6846 |
|
This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.
ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.
This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. |
|
| |
| RFC 6847 | Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | D. Melman, T. Mizrahi, D. Eastlake 3rd. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6847 |
|
Fibre Channel over Ethernet (FCoE) and Transparent Interconnection ofLots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's MediaAccess Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. |
|
| |
| RFC 6848 | Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George. |
| Date: | January 2013 |
| Formats: | txt json html |
| Updates: | RFC 4776, RFC 5222 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6848 |
|
New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. |
|
| |
| RFC 6849 | An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback |
| |
| Authors: | H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6849 |
|
The wide deployment of Voice over IP (VoIP), real-time text, andVideo over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real- time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics. |
|
| |
| RFC 6850 | Definitions of Managed Objects for Routing Bridges (RBridges) |
| |
| Authors: | A. Rijhsinghani, K. Zebrose. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6850 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as aTRILL Switch, based on the IETF TRILL (Transparent Interconnection ofLots of Links) protocol. |
|
| |
| RFC 6851 | Internet Message Access Protocol (IMAP) - MOVE Extension |
| |
| Authors: | A. Gulbrandsen, N. Freed, Ed.. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6851 |
|
This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. |
|
| |
| RFC 6852 | Affirmation of the Modern Paradigm for Standards |
| |
| Authors: | R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6852 |
|
On 29 August 2012, the leaders of the IEEE Standards Association, theIAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. |
|
| |
| RFC 6853 | DHCPv6 Redundancy Deployment Considerations |
| |
| Authors: | J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. |
| Date: | February 2013 |
| Formats: | txt html json |
| Also: | BCP 0180 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6853 |
|
This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services. |
|
| |
| RFC 6854 | Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields |
| |
|
|
The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or"Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in"Resent-From:" and "Resent-Sender:", in certain situations. |
|
| |
| RFC 6855 | IMAP Support for UTF-8 |
| |
| Authors: | P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.. |
| Date: | March 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 5738 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6855 |
|
This specification extends the Internet Message Access Protocol(IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738. |
|
| |
| RFC 6856 | Post Office Protocol Version 3 (POP3) Support for UTF-8 |
| |
| Authors: | R. Gellens, C. Newman, J. Yao, K. Fujiwara. |
| Date: | March 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 5721 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6856 |
|
This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings. |
|
| |
| RFC 6857 | Post-Delivery Message Downgrading for Internationalized Email Messages |
| |
| Authors: | K. Fujiwara. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6857 |
|
The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements. |
|
| |
| RFC 6858 | Simplified POP and IMAP Downgrading for Internationalized Email |
| |
|
|
This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results. |
|
| |
| RFC 6859 | Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership |
| |
|
|
RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative OversightCommittee (IAOC) was formed; that body is not covered by RFC 3777.There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of theIAB, the IESG, and the IAOC. |
|
| |
| RFC 6860 | Hiding Transit-Only Networks in OSPF |
| |
|
|
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link StateAdvertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.
This document updates RFCs 2328 and 5340. |
|
| |
| RFC 6861 | The "create-form" and "edit-form" Link Relations |
| |
| Authors: | I. Dzmanashvili. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6861 |
|
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. |
|
| |
| RFC 6862 | Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements |
| |
| Authors: | G. Lebovitz, M. Bhatia, B. Weis. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6862 |
|
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying andAuthentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for RoutingProtocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security. |
|
| |
| RFC 6863 | Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide |
| |
| Authors: | S. Hartman, D. Zhang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6863 |
|
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication forRouting Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway. |
|
| |
| RFC 6864 | Updated Specification of the IPv4 ID Field |
| |
|
|
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. |
|
| |
| RFC 6865 | Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME |
| |
| Authors: | V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6865 |
|
This document describes a fully-specified simple Forward ErrorCorrection (FEC) scheme for Reed-Solomon codes over the finite field(also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance. |
|
| |
| RFC 6866 | Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6866 |
|
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses. |
|
| |
| RFC 6867 | An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) |
| |
| Authors: | Y. Nir, Q. Wu. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6867 |
|
This document updates the Internet Key Exchange Protocol version 2(IKEv2) described in RFC 5996. This extension allows an IKE SecurityAssociation (SA) to be created and authenticated using the ExtensibleAuthentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. |
|
| |
| RFC 6868 | Parameter Value Encoding in iCalendar and vCard |
| |
|
|
This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications. |
|
| |
| RFC 6869 | vCard KIND:device |
| |
| Authors: | G. Salgueiro, J. Clarke, P. Saint-Andre. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6869 |
|
This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). |
|
| |
| RFC 6870 | Pseudowire Preferential Forwarding Status Bit |
| |
|
|
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured betweenProvider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes inMulti-Segment Pseudowire (MS-PW) applications.
In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.
In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.
Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV. |
|
| |
| RFC 6871 | Session Description Protocol (SDP) Media Capabilities Negotiation |
| |
| Authors: | R. Gilman, R. Even, F. Andreasen. |
| Date: | February 2013 |
| Formats: | txt json html |
| Updates: | RFC 5939 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6871 |
|
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP.The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
This document updates the IANA Considerations of RFC 5939. |
|
| |
| RFC 6872 | The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model |
| |
| Authors: | V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6872 |
|
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends.Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of aSIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents. |
|
| |
| RFC 6873 | Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) |
| |
| Authors: | G. Salgueiro, V. Gurbani, A. B. Roach. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7355 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6873 |
|
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. |
|
| |
| RFC 6874 | Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers |
| |
| Authors: | B. Carpenter, S. Cheshire, R. Hinden. |
| Date: | February 2013 |
| Formats: | txt json html |
| Updates: | RFC 3986 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6874 |
|
This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id&rt; in the IPv6 Scoped Address Architecture(RFC 4007), can be represented in a literal IPv6 address and in aUniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. |
|
| |
| RFC 6875 | The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan |
| |
| Authors: | S. Kamei, T. Momose, T. Inoue, T. Nishitani. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6875 |
|
This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for theALTO architecture and especially for application-independent ALTO- like server operation. |
|
| |
| RFC 6876 | A Posture Transport Protocol over TLS (PT-TLS) |
| |
| Authors: | P. Sangster, N. Cam-Winget, J. Salowey. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6876 |
|
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network EndpointAssessment (NEA) message exchange under the protection of a TransportLayer Security (TLS) secured tunnel. |
|
| |
| RFC 6877 | 464XLAT: Combination of Stateful and Stateless Translation |
| |
| Authors: | M. Mawatari, M. Kawashima, C. Byrne. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6877 |
|
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. |
|
| |
| RFC 6878 | IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field |
| |
|
|
This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261. |
|
| |
| RFC 6879 | IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods |
| |
| Authors: | S. Jiang, B. Liu, B. Carpenter. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6879 |
|
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation. |
|
| |
| RFC 6880 | An Information Model for Kerberos Version 5 |
| |
| Authors: | L. Johansson. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6880 |
|
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center(KDC). This document describes the services exposed by an administrative interface to a KDC. |
|
| |
| RFC 6881 | Best Current Practice for Communications Services in Support of Emergency Calling |
| |
|
|
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. |
|
| |
| RFC 6882 | Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) |
| |
| Authors: | K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6882 |
|
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated usingBGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs. |
|
| |
| RFC 6883 | IPv6 Guidance for Internet Content Providers and Application Service Providers |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6883 |
|
This document provides guidance and suggestions for Internet ContentProviders and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users. |
|
| |
| RFC 6884 | RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) |
| |
| Authors: | Z. Fang. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6884 |
|
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-WidebandCodec (EVRC-NW). Three media type registrations are included forEVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email. |
|
| |
| RFC 6885 | Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) |
| |
| Authors: | M. Blanchet, A. Sullivan. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6885 |
|
If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing DomainNames in Applications (here called IDNA2003) defined and usedStringprep and Nameprep. Other protocols subsequently definedStringprep profiles. A new approach different from Stringprep andNameprep is used for a revision of IDNA2003 (called IDNA2008). OtherStringprep profiles need to be similarly updated, or a replacement ofStringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. |
|
| |
| RFC 6886 | NAT Port Mapping Protocol (NAT-PMP) |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6886 |
|
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it.From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol(PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements. |
|
| |
| RFC 6887 | Port Control Protocol (PCP) |
| |
|
|
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by aNetwork Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. |
|
| |
| RFC 6888 | Common Requirements for Carrier-Grade NATs (CGNs) |
| |
| Authors: | S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida. |
| Date: | April 2013 |
| Formats: | txt json html |
| Updates: | RFC 4787 |
| Also: | BCP 0127 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6888 |
|
This document defines common requirements for Carrier-Grade NATs(CGNs). It updates RFC 4787. |
|
| |
| RFC 6889 | Analysis of Stateful 64 Translation |
| |
| Authors: | R. Penno, T. Saxena, M. Boucadair, S. Sivakumar. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6889 |
|
Due to specific problems, Network Address Translation - ProtocolTranslation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. |
|
| |
| RFC 6890 | Special-Purpose IP Address Registries |
| |
|
|
This memo reiterates the assignment of an IPv4 address block(192.0.0.0/24) to IANA. It also instructs IANA to restructure itsIPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special- purpose address blocks, maintaining a common set of information regarding each address block.
This memo obsoletes RFCs 4773, 5156, 5735, and 5736. |
|
| |
| RFC 6891 | Extension Mechanisms for DNS (EDNS(0)) |
| |
|
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletesRFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. |
|
| |
| RFC 6892 | The 'describes' Link Relation Type |
| |
| Authors: | E. Wilde. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6892 |
|
This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type. |
|
| |
| RFC 6893 | A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) |
| |
| Authors: | P. Higgs, P. Szucs. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6893 |
|
This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF. |
|
| |
| RFC 6894 | Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection |
| |
| Authors: | R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6894 |
|
This document describes the methodology for benchmarking MPLS FastReroute (FRR) protection mechanisms for link and node protection.This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS TrafficEngineered (MPLS-TE) tunnels. |
|
| |
| RFC 6895 | Domain Name System (DNS) IANA Considerations |
| |
|
|
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. |
|
| |
| RFC 6896 | SCS: KoanLogic's Secure Cookie Sessions for HTTP |
| |
| Authors: | S. Barbato, S. Dorigotti, T. Fossati, Ed.. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6896 |
|
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin- timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content viaHTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, HomeOffice (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering. |
|
| |
| RFC 6897 | Multipath TCP (MPTCP) Application Interface Considerations |
| |
| Authors: | M. Scharf, A. Ford. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6897 |
|
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications.Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications. |
|
| |
| RFC 6898 | Link Management Protocol Behavior Negotiation and Configuration Modifications |
| |
|
|
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled byGeneralized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818. |
|
