Internet Documents

RFCs 6400 - 6499s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
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
 
Authors:J. Schaad.
Date:November 2011
Formats:txt html json
Updates:RFC 5272, RFC 5273, RFC 5274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6402
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
 
Authors:R. Gellens, J. Klensin.
Date:November 2011
Formats:txt json html
Obsoletes:RFC 4409
Updated by:RFC 8314
Also:STD 0072
Status:INTERNET STANDARD
DOI:10.17487/RFC 6409
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
 
Authors:R. Housley, D. Crocker, E. Burger.
Date:October 2011
Formats:txt json html
Updates:RFC 2026
Also:BCP 0009
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6410
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
 
Authors:T. Lemon, Q. Wu.
Date:December 2011
Formats:txt html json
Updates:RFC 3315
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6422
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
 
Authors:N. Bahadur, K. Kompella, G. Swallow.
Date:November 2011
Formats:txt json html
Obsoleted by:RFC 8029
Updates:RFC 4379
Updated by:RFC 7537
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6424
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
 
Authors:P. Hoffman.
Date:November 2011
Formats:txt html json
Updates:RFC 6292
Status:INFORMATIONAL
DOI:10.17487/RFC 6433
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
 
Authors:E. Jankiewicz, J. Loughney, T. Narten.
Date:December 2011
Formats:txt json html
Obsoletes:RFC 4294
Obsoleted by:RFC 8504
Status:INFORMATIONAL
DOI:10.17487/RFC 6434
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
 
Authors:S. Amante, B. Carpenter, S. Jiang, J. Rajahalme.
Date:November 2011
Formats:txt html json
Obsoletes:RFC 3697
Updates:RFC 2205, RFC 2460
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6437
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
 
Authors:R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu.
Date:November 2011
Formats:txt json html
Obsoleted by:RFC 8139
Updates:RFC 6325
Updated by:RFC 7180
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6439
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
 
Authors:L. Vegoda.
Date:November 2011
Formats:txt html json
Also:BCP 0171
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6441
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
 
Authors:J. Polk, B. Rosen, J. Peterson.
Date:December 2011
Formats:txt json html
Updated by:RFC 8262, RFC 8787
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6442
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
 
Authors:I. Fette, A. Melnikov.
Date:December 2011
Formats:txt html json
Updated by:RFC 7936, RFC 8307, RFC 8441
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6455
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)
 
Authors:M. Salter, R. Housley.
Date:January 2012
Formats:txt html json
Obsoletes:RFC 5430
Updated by:RFC 8996
Status:HISTORIC
DOI:10.17487/RFC 6460
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
 
Authors:L. Martini, G. Swallow, G. Heron, M. Bocci.
Date:May 2012
Formats:txt html json
Updates:RFC 5885
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6478
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)
 
Authors:G. Huston.
Date:February 2012
Formats:txt html json
Obsoleted by:RFC 7935
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6485
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
 
Authors:G. Huston, G. Michaelson, R. Loomans.
Date:February 2012
Formats:txt json html
Updated by:RFC 7318, RFC 8209
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6487
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.