| |
| RFC 6401 | RSVP Extensions for Admission Priority |
| |
| Authors: | F. Le Faucheur, J. Polk, K. Carlberg. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6401 |
|
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol(RSVP) that can be used to support such an admission priority capability at the network layer.
Based on current security concerns, these extensions are intended for use in a single administrative domain. |
|
| |
| RFC 6402 | Certificate Management over CMS (CMC) Updates |
| |
|
|
This document contains a set of updates to the base syntax for CMC, aCertificate Management protocol using the Cryptographic MessageSyntax (CMS). This document updates RFC 5272, RFC 5273, and RFC5274.
The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject InformationAccess value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. |
|
| |
| RFC 6403 | Suite B Profile of Certificate Management over CMS |
| |
| Authors: | L. Zieglar, S. Turner, M. Peck. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6403 |
|
The United States government has published guidelines for "NSASuite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. |
|
| |
| RFC 6404 | Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures |
| |
| Authors: | J. Seedorf, S. Niccolini, E. Chen, H. Scholz. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6404 |
|
The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements forSPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), theLocation Routing Function (LRF), the Signaling Function (SF), and theMedia Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP andRTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. EachSSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. |
|
| |
| RFC 6405 | Voice over IP (VoIP) SIP Peering Use Cases |
| |
| Authors: | A. Uzelac, Ed., Y. Lee, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6405 |
|
This document depicts many common Voice over IP (VoIP) use cases forSession Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. |
|
| |
| RFC 6406 | Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture |
| |
| Authors: | D. Malas, Ed., J. Livingood, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6406 |
|
This document defines a peering architecture for the SessionInitiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. |
|
| |
| RFC 6407 | The Group Domain of Interpretation |
| |
| Authors: | B. Weis, S. Rowles, T. Hardjono. |
| Date: | October 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3547 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6407 |
|
This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. |
|
| |
| RFC 6408 | Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage |
| |
| Authors: | M. Jones, J. Korhonen, L. Morand. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 3588 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6408 |
|
The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol.However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-NamingAuthority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. |
|
| |
| RFC 6409 | Message Submission for Mail |
| |
|
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay is unaffected, and continues to use SMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
| |
| RFC 6410 | Reducing the Standards Track to Two Maturity Levels |
| |
|
|
This document updates the Internet Engineering Task Force (IETF)Standards Process defined in RFC 2026. Primarily, it reduces theStandards Process from three Standards Track maturity levels to two. |
|
| |
| RFC 6411 | Applicability of Keying Methods for RSVP Security |
| |
| Authors: | M. Behringer, F. Le Faucheur, B. Weis. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6411 |
|
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. |
|
| |
| RFC 6412 | Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence |
| |
| Authors: | S. Poretsky, B. Imhoff, K. Michielsen. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6412 |
|
This document describes the terminology for benchmarking link-stateInterior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS andOSPF. |
|
| |
| RFC 6413 | Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence |
| |
| Authors: | S. Poretsky, B. Imhoff, K. Michielsen. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6413 |
|
This document describes the methodology for benchmarking Link-StateInterior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS andOSPF. |
|
| |
| RFC 6414 | Benchmarking Terminology for Protection Performance |
| |
| Authors: | S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6414 |
|
This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms.The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS),Virtual Router Redundancy Protocol (VRRP), Stateful High Availability(HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). |
|
| |
| RFC 6415 | Web Host Metadata |
| |
| Authors: | E. Hammer-Lahav, Ed., B. Cook. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6415 |
|
This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. |
|
| |
| RFC 6416 | RTP Payload Format for MPEG-4 Audio/Visual Streams |
| |
| Authors: | M. Schmidt, F. de Bont, S. Doehla, J. Kim. |
| Date: | October 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3016 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6416 |
|
This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision ofRFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.
For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC3016 is provided to update and complete the specification and to enable interoperable implementations. |
|
| |
| RFC 6417 | How to Contribute Research Results to Internet Standardization |
| |
| Authors: | P. Eardley, L. Eggert, M. Bagnulo, R. Winter. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6417 |
|
The development of new technology is driven by scientific research.The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of theInternet originate in the related academic research communities.Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.
For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. |
|
| |
| RFC 6418 | Multiple Interfaces and Provisioning Domains Problem Statement |
| |
| Authors: | M. Blanchet, P. Seite. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6418 |
|
This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. |
|
| |
| RFC 6419 | Current Practices for Multiple-Interface Hosts |
| |
| Authors: | M. Wasserman, P. Seite. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6419 |
|
An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. |
|
| |
| RFC 6420 | PIM Multi-Topology ID (MT-ID) Join Attribute |
| |
| Authors: | Y. Cai, H. Ou. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6420 |
|
This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. |
|
| |
| RFC 6421 | Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) |
| |
| Authors: | D. Nelson, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6421 |
|
This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). |
|
| |
| RFC 6422 | Relay-Supplied DHCP Options |
| |
|
|
DHCPv6 relay agents cannot communicate with DHCPv6 clients directly.However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.
This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. |
|
| |
| RFC 6423 | Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | H. Li, L. Martini, J. He, F. Huang. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updates: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6423 |
|
This document describes the requirements for using the GenericAssociated Channel Label (GAL) in pseudowires (PWs) in MPLS TransportProfile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. |
|
| |
| RFC 6424 | Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels |
| |
|
|
This document describes methods for performing LSP ping (specified inRFC 4379) traceroute over MPLS tunnels and for traceroute of stitchedMPLS Label Switched Paths (LSPs). The techniques outlined in RFC4379 are insufficient to perform traceroute Forwarding EquivalencyClass (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a newTLV that, along with other procedures outlined in this document, can be used to trace such LSPs. |
|
| |
| RFC 6425 | Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping |
| |
| Authors: | S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6425 |
|
Recent proposals have extended the scope of Multiprotocol LabelSwitching (MPLS) Label Switched Paths (LSPs) to encompass point-to- multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".
The scope of this document is fault detection and isolation for P2MPMPLS LSPs. This documents does not replace any of the mechanisms ofLSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.
This document updates RFC 4379. |
|
| |
| RFC 6426 | MPLS On-Demand Connectivity Verification and Route Tracing |
| |
| Authors: | E. Gray, N. Bahadur, S. Boutros, R. Aggarwal. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6426 |
|
Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths(LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLSTransport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions inMPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. |
|
| |
| RFC 6427 | MPLS Fault Management Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6427 |
|
This document specifies Operations, Administration, and Maintenance(OAM) messages to indicate service disruptive conditions for MPLS- based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. |
|
| |
| RFC 6428 | Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile |
| |
| Authors: | D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6428 |
|
Continuity Check, Proactive Connectivity Verification, and RemoteDefect Indication functionalities are required for MPLS TransportProfile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments ContinuityCheck in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, orSection.
This document specifies specific extensions to BidirectionalForwarding Detection (BFD) and methods for proactive ContinuityCheck, Continuity Verification, and Remote Defect Indication forMPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. |
|
| |
| RFC 6429 | TCP Sender Clarification for Persist Condition |
| |
| Authors: | M. Bashyam, M. Jethanandani, A. Ramaiah. |
| Date: | December 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9293 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6429 |
|
This document clarifies the Zero Window Probes (ZWPs) described inRFC 1122 ("Requirements for Internet Hosts -- Communication Layers").In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified inRFC 1122. |
|
| |
| RFC 6430 | Email Feedback Report Type Value: not-spam |
| |
| Authors: | K. Li, B. Leiba. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6430 |
|
This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. |
|
| |
| RFC 6431 | Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) |
| |
| Authors: | M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6431 |
|
This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. |
|
| |
| RFC 6432 | Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses |
| |
| Authors: | R. Jesske, L. Liess. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6432 |
|
Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. |
|
| |
| RFC 6433 | Requirements for a Working Group Milestones Tool |
| |
|
|
The IETF intends to provide a new tool to Working Group chairs andArea Directors for the creation and updating of milestones forWorking Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. |
|
| |
| RFC 6434 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 4294. |
|
| |
| RFC 6435 | MPLS Transport Profile Lock Instruct and Loopback Functions |
| |
| Authors: | S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 6371 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6435 |
|
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. |
|
| |
| RFC 6436 | Rationale for Update to the IPv6 Flow Label Specification |
| |
| Authors: | S. Amante, B. Carpenter, S. Jiang. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6436 |
|
Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697.Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. |
|
| |
| RFC 6437 | IPv6 Flow Label Specification |
| |
|
|
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. |
|
| |
| RFC 6438 | Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels |
| |
| Authors: | B. Carpenter, S. Amante. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6438 |
|
The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. |
|
| |
| RFC 6439 | Routing Bridges (RBridges): Appointed Forwarders |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to IntermediateSystem) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multipleRBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called"Appointed Forwarders", with the intent that native traffic in eachVLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the AppointedForwarder mechanism; thus, it updates RFC 6325. |
|
| |
| RFC 6440 | The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option |
| |
| Authors: | G. Zorn, Q. Wu, Y. Wang. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6440 |
|
In order to derive a Domain-Specific Root Key (DSRK) from theExtended Master Session Key (EMSK) generated as a side effect of anExtensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.
This document specifies a Dynamic Host Configuration ProtocolVersion 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. |
|
| |
| RFC 6441 | Time to Remove Filters for Previously Unallocated IPv4 /8s |
| |
|
|
It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.
This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. |
|
| |
| RFC 6442 | Location Conveyance for the Session Initiation Protocol |
| |
|
|
This document defines an extension to the Session Initiation Protocol(SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of theLocation Target. |
|
| |
| RFC 6443 | Framework for Emergency Calling Using Internet Multimedia |
| |
| Authors: | B. Rosen, H. Schulzrinne, J. Polk, A. Newton. |
| Date: | December 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7852 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6443 |
|
The IETF has standardized various aspects of placing emergency calls.This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. |
|
| |
| RFC 6444 | Location Hiding: Problem Statement and Requirements |
| |
| Authors: | H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6444 |
|
The emergency services architecture developed in the IETF EmergencyContext Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point(PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.
This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or theInternet Service Provider (ISP) are only willing to disclose limited or no location information. |
|
| |
| RFC 6445 | Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute |
| |
| Authors: | T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6445 |
|
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. |
|
| |
| RFC 6446 | Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control |
| |
| Authors: | A. Niemi, K. Kiss, S. Loreto. |
| Date: | January 2012 |
| Formats: | txt json html |
| Updates: | RFC 3265 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6446 |
|
This document specifies mechanisms for adjusting the rate of SessionInitiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. |
|
| |
| RFC 6447 | Filtering Location Notifications in the Session Initiation Protocol (SIP) |
| |
| Authors: | R. Mahy, B. Rosen, H. Tschofenig. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6447 |
|
This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package.The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format LocationObject (PIDF-LO). |
|
| |
| RFC 6448 | The Unencrypted Form of Kerberos 5 KRB-CRED Message |
| |
| Authors: | R. Yount. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6448 |
|
The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. |
|
| |
| RFC 6449 | Complaint Feedback Loop Operational Recommendations |
| |
| Authors: | J. Falk, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6449 |
|
Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.
This document is the result of cooperative efforts within theMessaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. |
|
| |
| RFC 6450 | Multicast Ping Protocol |
| |
| Authors: | S. Venaas. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6450 |
|
The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". |
|
| |
| RFC 6451 | Location-to-Service Translation (LoST) Protocol Extensions |
| |
| Authors: | A. Forte, H. Schulzrinne. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6451 |
|
An important class of location-based services answers the question,"What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". |
|
| |
| RFC 6452 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 |
| |
| Authors: | P. Faltstrom, Ed., P. Hoffman, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6452 |
|
This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode6.0. |
|
| |
| RFC 6453 | A URN Namespace for the Open Grid Forum (OGF) |
| |
| Authors: | F. Dijkstra, R. Hughes-Jones. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6453 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. |
|
| |
| RFC 6454 | The Web Origin Concept |
| |
| Authors: | A. Barth. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6454 |
|
This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. |
|
| |
| RFC 6455 | The WebSocket Protocol |
| |
|
|
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., usingXMLHttpRequest or <iframe&rt;s and long polling). |
|
| |
| RFC 6456 | Multi-Segment Pseudowires in Passive Optical Networks |
| |
| Authors: | H. Li, R. Zheng, A. Farrel. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6456 |
|
This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising aPassive Optical Network (PON) and an MPLS Packet Switched Network(PSN).
PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) TerminatingProvider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.
This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network TerminationManagement and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.
This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. |
|
| |
| RFC 6457 | PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering |
| |
| Authors: | T. Takeda, Ed., A. Farrel. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6457 |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS(GMPLS).
MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element(PCE) Discovery".
This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. |
|
| |
| RFC 6458 | Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6458 |
|
This document describes a mapping of the Stream Control TransmissionProtocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. |
|
| |
| RFC 6459 | IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) |
| |
| Authors: | J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6459 |
|
The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rdGeneration Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. |
|
| |
| RFC 6460 | Suite B Profile for Transport Layer Security (TLS) |
| |
|
|
The United States government has published guidelines for "NSA SuiteB Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. |
|
| |
| RFC 6461 | Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements |
| |
| Authors: | S. Channabasappa, Ed.. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6461 |
|
This document captures the use cases and associated requirements for interfaces that provision session establishment data into SessionInitiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". |
|
| |
| RFC 6462 | Report from the Internet Privacy Workshop |
| |
| Authors: | A. Cooper. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6462 |
|
On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society(ISOC), and MIT's Computer Science and Artificial IntelligenceLaboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protectiveInternet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps.For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. |
|
| |
| RFC 6463 | Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 |
| |
| Authors: | J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6463 |
|
This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy MobileIPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. |
|
| |
| RFC 6464 | A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication |
| |
| Authors: | J. Lennox, Ed., E. Ivov, E. Marocco. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6464 |
|
This document defines a mechanism by which packets of Real-timeTransport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. |
|
| |
| RFC 6465 | A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication |
| |
| Authors: | E. Ivov, Ed., E. Marocco, Ed., J. Lennox. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6465 |
|
This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. |
|
| |
| RFC 6466 | IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) |
| |
| Authors: | G. Salgueiro. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6466 |
|
This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the SessionDescription Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. |
|
| |
| RFC 6467 | Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) |
| |
| Authors: | T. Kivinen. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6467 |
|
This document defines a generic way for Internet Key Exchange version2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods. |
|
| |
| RFC 6468 | Sieve Notification Mechanism: SIP MESSAGE |
| |
| Authors: | A. Melnikov, B. Leiba, K. Li. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6468 |
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. |
|
| |
| RFC 6469 | RTP Payload Format for DV (IEC 61834) Video |
| |
| Authors: | K. Kobayashi, K. Mishima, S. Casner, C. Bormann. |
| Date: | December 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3189 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6469 |
|
This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. |
|
| |
| RFC 6470 | Network Configuration Protocol (NETCONF) Base Notifications |
| |
| Authors: | A. Bierman. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6470 |
|
The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications.Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines aYANG module that allows a NETCONF client to receive notifications for some common system events. |
|
| |
| RFC 6471 | Overview of Best Email DNS-Based List (DNSBL) Operational Practices |
| |
| Authors: | C. Lewis, M. Sergeant. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6471 |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering.This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. |
|
| |
| RFC 6472 | Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP |
| |
| Authors: | W. Kumari, K. Sriram. |
| Date: | December 2011 |
| Formats: | txt json html |
| Also: | BCP 0172 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6472 |
|
This document recommends against the use of the AS_SET andAS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. |
|
| |
| RFC 6473 | vCard KIND:application |
| |
| Authors: | P. Saint-Andre. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6473 |
|
This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. |
|
| |
| RFC 6474 | vCard Format Extensions: Place of Birth, Place and Date of Death |
| |
| Authors: | K. Li, B. Leiba. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6474 |
|
The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. |
|
| |
| RFC 6475 | Proxy Mobile IPv6 Management Information Base |
| |
| Authors: | G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6475 |
|
This memo defines a portion of the Proxy Mobile IPv6 ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6(PMIPv6) entity. |
|
| |
| RFC 6476 | Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | P. Gutmann. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6476 |
|
This document specifies the conventions for using MessageAuthentication Code (MAC) encryption with the Cryptographic MessageSyntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security(SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. |
|
| |
| RFC 6477 | Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail |
| |
| Authors: | A. Melnikov, G. Lunt. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6477 |
|
A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHSElements of Service are defined as a set of extensions to the ITU-TX.400 (1992) international standards and are specified in STANAG 4406Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. |
|
| |
| RFC 6478 | Pseudowire Status for Static Pseudowires |
| |
|
|
This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allowsPW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection(BFD) is used to convey PW status-signaling information. |
|
| |
| RFC 6479 | IPsec Anti-Replay Algorithm without Bit Shifting |
| |
| Authors: | X. Zhang, T. Tsou. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6479 |
|
This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) andEncapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. |
|
| |
| RFC 6480 | An Infrastructure to Support Secure Internet Routing |
| |
| Authors: | M. Lepinski, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6480 |
|
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space andAutonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise theRPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. |
|
| |
| RFC 6481 | A Profile for Resource Certificate Repository Structure |
| |
| Authors: | G. Huston, R. Loomans, G. Michaelson. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6481 |
|
This document defines a profile for the structure of the ResourcePublic Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates,Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. |
|
| |
| RFC 6482 | A Profile for Route Origin Authorizations (ROAs) |
| |
| Authors: | M. Lepinski, S. Kent, D. Kong. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9582 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6482 |
|
This document defines a standard profile for Route OriginAuthorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. |
|
| |
| RFC 6483 | Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) |
| |
| Authors: | G. Huston, G. Michaelson. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6483 |
|
This document defines the semantics of a Route Origin Authorization(ROA) in terms of the context of an application of the ResourcePublic Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. |
|
| |
| RFC 6484 | Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Kent, D. Kong, K. Seo, R. Watro. |
| Date: | February 2012 |
| Formats: | txt html json |
| Also: | BCP 0173 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6484 |
|
This document describes the certificate policy for a Public KeyInfrastructure (PKI) used to support attestations about InternetNumber Resource (INR) holdings. Each organization that distributesIP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. |
|
| |
| RFC 6485 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 6486 | Manifests for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Austein, G. Huston, S. Kent, M. Lepinski. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9286 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6486 |
|
This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. |
|
| |
| RFC 6487 | A Profile for X.509 PKIX Resource Certificates |
| |
|
|
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and CertificateRevocation List (CRL) syntax in the Resource Public KeyInfrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. |
|
| |
| RFC 6488 | Signed Object Template for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | M. Lepinski, A. Chi, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 9589 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6488 |
|
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. |
|
| |
| RFC 6489 | Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | G. Huston, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Also: | BCP 0174 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6489 |
|
This document describes how a Certification Authority (CA) in theResource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. |
|
| |
| RFC 6490 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7730 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6490 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). |
|
| |
| RFC 6491 | Resource Public Key Infrastructure (RPKI) Objects Issued by IANA |
| |
| Authors: | T. Manderson, L. Vegoda, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6491 |
|
This document provides specific direction to IANA as to the ResourcePublic Key Infrastructure (RPKI) objects it should issue. |
|
| |
| RFC 6492 | A Protocol for Provisioning Resource Certificates |
| |
| Authors: | G. Huston, R. Loomans, B. Ellacott, R. Austein. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6492 |
|
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties.The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. |
|
| |
| RFC 6493 | The Resource Public Key Infrastructure (RPKI) Ghostbusters Record |
| |
| Authors: | R. Bush. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6493 |
|
In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI GhostbustersRecord containing human contact information that may be verified(indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. |
|
| |
| RFC 6494 | Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) |
| |
| Authors: | R. Gagliano, S. Krishnan, A. Kukec. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 3971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6494 |
|
SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. |
|
| |
| RFC 6495 | Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields |
| |
| Authors: | R. Gagliano, S. Krishnan, A. Kukec. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 3971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6495 |
|
SEcure Neighbor Discovery (SEND) defines the Name Type field in theICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). |
|
| |
| RFC 6496 | Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) |
| |
| Authors: | S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6496 |
|
SEcure Neighbor Discovery (SEND) specifies a method for securingNeighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. |
|
| |
| RFC 6497 | BCP 47 Extension T - Transformed Content |
| |
| Authors: | M. Davis, A. Phillips, Y. Umaoka, C. Falk. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6497 |
|
This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. |
|
| |
| RFC 6498 | Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package |
| |
| Authors: | J. Stone, R. Kumar, F. Andreasen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6498 |
|
This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package andFax package with VBD, redundancy, and FEC. |
|
