| |
| RFC 6001 | Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) |
| |
|
|
There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).
This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer /Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. |
|
| |
| RFC 6002 | Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions |
| |
|
|
This document describes two technology-independent extensions toGeneralized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel SwitchingCapable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path(LSP). |
|
| |
| RFC 6003 | Ethernet Traffic Parameters |
| |
|
|
This document describes the support of Metro Ethernet Forum (MEF)Ethernet traffic parameters as described in MEF10.1 when usingGeneralized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. |
|
| |
| RFC 6004 | Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching |
| |
| Authors: | L. Berger, D. Fedyk. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6004 |
|
This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching(GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of theMetro Ethernet Forum (MEF) and International Telecommunication Union(ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered. |
|
| |
| RFC 6005 | Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) |
| |
| Authors: | L. Berger, D. Fedyk. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6005 |
|
This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI).This document supports the types of switching required by theEthernet services that have been defined in the context of the MetroEthernet Forum (MEF) and International Telecommunication Union (ITU)G.8011. This document is the UNI companion to "Generalized MPLS(GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet ServiceSwitching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support theUNI. |
|
| |
| RFC 6006 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. |
| Date: | September 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8306 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6006 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. |
|
| |
| RFC 6007 | Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations |
| |
| Authors: | I. Nishioka, D. King. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6007 |
|
A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest(PCReq) message.
This document does not specify the PCEP SVEC object or procedure.This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests.The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. |
|
| |
| RFC 6008 | Authentication-Results Registration for Differentiating among Cryptographic Results |
| |
| Authors: | M. Kucherawy. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6008 |
|
This memo updates the registry of properties in Authentication-Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. |
|
| |
| RFC 6009 | Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions |
| |
| Authors: | N. Freed. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6009 |
|
This document describes the "envelope-dsn", "redirect-dsn","envelope-deliverby", and "redirect-deliverby" extensions to theSieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) andDeliver-By SMTP extensions, respectively. The "redirect-dsn" and"redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. |
|
| |
| RFC 6010 | Cryptographic Message Syntax (CMS) Content Constraints Extension |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6010 |
|
This document specifies the syntax and semantics for theCryptographic Message Syntax (CMS) content constraints extension.This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMSAuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. |
|
| |
| RFC 6011 | Session Initiation Protocol (SIP) User Agent Configuration |
| |
| Authors: | S. Lawrence, Ed., J. Elwell. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6011 |
|
This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. |
|
| |
| RFC 6012 | Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog |
| |
|
|
This document describes the transport of syslog messages over theDatagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. |
|
| |
| RFC 6013 | TCP Cookie Transactions (TCPCT) |
| |
|
|
TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. |
|
| |
| RFC 6014 | Cryptographic Algorithm Identifier Allocation for DNSSEC |
| |
|
|
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required forDNSSEC implementations. |
|
| |
| RFC 6015 | RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) |
| |
| Authors: | A. Begen. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6015 |
|
This document defines a new RTP payload format for the Forward ErrorCorrection (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB-IPTV) Application-layer FEC specification. |
|
| |
| RFC 6016 | Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs |
| |
| Authors: | B. Davie, F. Le Faucheur, A. Narayanan. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6016 |
|
RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers andProvider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. |
|
| |
| RFC 6017 | Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field |
| |
| Authors: | K. Meadors, Ed.. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6017 |
|
With the maturity of the Electronic Data Interchange - InternetIntegration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by allEDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. |
|
| |
| RFC 6018 | IPv4 and IPv6 Greynets |
| |
| Authors: | F. Baker, W. Harrop, G. Armitage. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6018 |
|
This note discusses a feature to support building Greynets for IPv4 and IPv6. |
|
| |
| RFC 6019 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
|
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. |
|
| |
| RFC 6020 | YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) |
| |
| Authors: | M. Bjorklund, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6020 |
|
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. |
|
| |
| RFC 6021 | Common YANG Data Types |
| |
| Authors: | J. Schoenwaelder, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6991 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6021 |
|
This document introduces a collection of common data types to be used with the YANG data modeling language. |
|
| |
| RFC 6022 | YANG Module for NETCONF Monitoring |
| |
| Authors: | M. Scott, M. Bjorklund. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6022 |
|
This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of aNETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema&rt; operation to retrieve them. |
|
| |
| RFC 6023 | A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) |
| |
| Authors: | Y. Nir, H. Tschofenig, H. Deng, R. Singh. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6023 |
|
This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association(SA) to be created and authenticated without generating a Child SA. |
|
| |
| RFC 6024 | Trust Anchor Management Requirements |
| |
| Authors: | R. Reddy, C. Wallace. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6024 |
|
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. |
|
| |
| RFC 6025 | ASN.1 Translation |
| |
| Authors: | C. Wallace, C. Gardiner. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6025 |
|
Abstract Syntax Notation One (ASN.1) is widely used throughout theIETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1.Instead, it addresses ASN.1 features that are used in IETF SecurityArea specifications with a focus on items that vary with the ASN.1 version. |
|
| |
| RFC 6026 | Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests |
| |
| Authors: | R. Sparks, T. Zourzouvillys. |
| Date: | September 2010 |
| Formats: | txt html json |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6026 |
|
This document normatively updates RFC 3261, the Session InitiationProtocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements followingRFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying theINVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. |
|
| |
| RFC 6027 | IPsec Cluster Problem Statement |
| |
| Authors: | Y. Nir. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6027 |
|
This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. |
|
| |
| RFC 6028 | Host Identity Protocol (HIP) Multi-Hop Routing Extension |
| |
| Authors: | G. Camarillo, A. Keranen. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6028 |
|
This document specifies two extensions to the Host Identity Protocol(HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. |
|
| |
| RFC 6029 | A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem |
| |
| Authors: | I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6029 |
|
A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming.Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. |
|
| |
| RFC 6030 | Portable Symmetric Key Container (PSKC) |
| |
| Authors: | P. Hoyer, M. Pei, S. Machani. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6030 |
|
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. |
|
| |
| RFC 6031 | Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6031 |
|
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. |
|
| |
| RFC 6032 | Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6032 |
|
This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS ContentConstraints (CCC) extension, which does not constrain theEncryptedData, EnvelopedData, and AuthEnvelopedData. |
|
| |
| RFC 6033 | Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, andAuthEnvelopedData. |
|
| |
| RFC 6034 | Unicast-Prefix-Based IPv4 Multicast Addresses |
| |
| Authors: | D. Thaler. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6034 |
|
This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. |
|
| |
| RFC 6035 | Session Initiation Protocol Event Package for Voice Quality Reporting |
| |
| Authors: | A. Pendleton, A. Clark, A. Johnston, H. Sinnreich. |
| Date: | November 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6035 |
|
This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.Voice call quality information derived from RTP Control ProtocolExtended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq- rtcpxr media type is also included. |
|
| |
| RFC 6036 | Emerging Service Provider Scenarios for IPv6 Deployment |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | October 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9386 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6036 |
|
This document describes practices and plans that are emerging amongInternet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. |
|
| |
| RFC 6037 | Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs |
| |
| Authors: | E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6037 |
|
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalizedMVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. |
|
| |
| RFC 6038 | Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features |
| |
| Authors: | A. Morton, L. Ciavattone. |
| Date: | October 2010 |
| Formats: | txt json html |
| Updates: | RFC 5357 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6038 |
|
This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. |
|
| |
| RFC 6039 | Issues with Existing Cryptographic Protection Methods for Routing Protocols |
| |
| Authors: | V. Manral, M. Bhatia, J. Jaeggli, R. White. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6039 |
|
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.
This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. |
|
| |
| RFC 6040 | Tunnelling of Explicit Congestion Notification |
| |
|
|
This document redefines how the explicit congestion notification(ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301IPsec ECN processing. On decapsulation, it updates both RFC 3168 andRFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification --PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. |
|
| |
| RFC 6041 | Forwarding and Control Element Separation (ForCES) Applicability Statement |
| |
| Authors: | A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6041 |
|
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. |
|
| |
| RFC 6042 | Transport Layer Security (TLS) Authorization Using KeyNote |
| |
|
|
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security(TLS) Handshake Protocol, according to guidelines in RFC 5878.Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. |
|
| |
| RFC 6043 | MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
|
|
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing.Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. |
|
| |
| RFC 6044 | Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) |
| |
|
|
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. |
|
| |
| RFC 6045 | Real-time Inter-network Defense (RID) |
| |
|
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter- network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. |
|
| |
| RFC 6046 | Transport of Real-time Inter-network Defense (RID) Messages |
| |
| Authors: | K. Moriarty, B. Trammell. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6546 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6046 |
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). |
|
| |
| RFC 6047 | iCalendar Message-Based Interoperability Protocol (iMIP) |
| |
|
|
This document, "iCalendar Message-Based Interoperability Protocol(iMIP)", specifies a binding from the iCalendar Transport-independentInteroperability Protocol (iTIP) to Internet email-based transports.Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC2046, RFC 2047, and RFC 2049), and then transported over SMTP. |
|
| |
| RFC 6048 | Network News Transfer Protocol (NNTP) Additions to LIST Command |
| |
|
|
This document defines a set of enhancements to the Network NewsTransfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.
This memo updates and formalizes the LIST DISTRIBUTIONS and LISTSUBSCRIPTIONS commands defined in RFC 2980. It also adds the LISTCOUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. |
|
| |
| RFC 6049 | Spatial Composition of Metrics |
| |
| Authors: | A. Morton, E. Stephan. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6049 |
|
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. |
|
| |
| RFC 6050 | A Session Initiation Protocol (SIP) Extension for the Identification of Services |
| |
| Authors: | K. Drage. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6050 |
|
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
The document also defines a URN to identify both services and UserAgent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. |
|
| |
| RFC 6051 | Rapid Synchronisation of RTP Flows |
| |
| Authors: | C. Perkins, T. Schierl. |
| Date: | November 2010 |
| Formats: | txt html json |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6051 |
|
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol(RTCP) timing rules to reduce the initial synchronisation delay forSSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. |
|
| |
| RFC 6052 | IPv6 Addressing of IPv4/IPv6 Translators |
| |
| Authors: | C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. |
| Date: | October 2010 |
| Formats: | txt json html |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6052 |
|
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. |
|
| |
| RFC 6053 | Implementation Report for Forwarding and Control Element Separation (ForCES) |
| |
| Authors: | E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. |
| Date: | November 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6984 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6053 |
|
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.
This document is an implementation report for the ForCES Protocol,Model, and the Stream Control Transmission Protocol-based TransportMapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. |
|
| |
| RFC 6054 | Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic |
| |
| Authors: | D. McGrew, B. Weis. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6054 |
|
Counter modes have been defined for block ciphers such as theAdvanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender.This memo describes the use of counter modes when applied to theEncapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. |
|
| |
| RFC 6055 | IAB Thoughts on Encodings for Internationalized Domain Names |
| |
| Authors: | D. Thaler, J. Klensin, S. Cheshire. |
| Date: | February 2011 |
| Formats: | txt html json |
| Updates: | RFC 2130 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6055 |
|
This document explores issues with Internationalized Domain Names(IDNs) that result from the use of various encoding schemes such asUTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today. |
|
| |
| RFC 6056 | Recommendations for Transport-Protocol Port Randomization |
| |
|
|
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the TransmissionControl Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, DestinationAddress, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such asTCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). |
|
| |
| RFC 6057 | Comcast's Protocol-Agnostic Congestion Management System |
| |
| Authors: | C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6057 |
|
This document describes the congestion management system of ComcastCable, a large cable broadband Internet Service Provider (ISP) in theU.S. Comcast completed deployment of this congestion management system on December 31, 2008. |
|
| |
| RFC 6058 | Transient Binding for Proxy Mobile IPv6 |
| |
| Authors: | M. Liebsch, Ed., A. Muhanna, O. Blume. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6058 |
|
This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the ProxyMobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. |
|
| |
| RFC 6059 | Simple Procedures for Detecting Network Attachment in IPv6 |
| |
| Authors: | S. Krishnan, G. Daley. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6059 |
|
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for DetectingNetwork Attachment in IPv6 hosts, and procedures for routers to support such services. |
|
| |
| RFC 6060 | Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) |
| |
| Authors: | D. Fedyk, H. Shah, N. Bitar, A. Takacs. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6060 |
|
This specification is complementary to the GMPLS Ethernet LabelSwitching Architecture and Framework and describes the technology- specific aspects of GMPLS control for Provider Backbone BridgeTraffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point(P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. |
|
| |
| RFC 6061 | Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) |
| |
| Authors: | B. Rosen. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6061 |
|
This document describes the Namespace Identifier (NID) "nena" forUniform Resource Name (URN) resources published by the NationalEmergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA RegistrySystem (NRS). |
|
| |
| RFC 6062 | Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations |
| |
| Authors: | S. Perreault, Ed., J. Rosenberg. |
| Date: | November 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6062 |
|
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator(NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers.TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from theTURN server. |
|
| |
| RFC 6063 | Dynamic Symmetric Key Provisioning Protocol (DSKPP) |
| |
| Authors: | A. Doherty, M. Pei, S. Machani, M. Nystrom. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6063 |
|
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client- server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
Two variations of the protocol support multiple usage scenarios.With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre- generated symmetric keys to a cryptographic module. |
|
| |
| RFC 6064 | SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service |
| |
| Authors: | M. Westerlund, P. Frojdh. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6064 |
|
The Packet-switched Streaming Service (PSS) and the MultimediaBroadcast/Multicast Service (MBMS) defined by 3GPP use the SessionDescription Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. |
|
| |
| RFC 6065 | Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings |
| |
| Authors: | K. Narayan, D. Nelson, R. Presuhn, Ed.. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6065 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting(AAA) services, such as the Remote Authentication Dial-In UserService (RADIUS), to dynamically update user-to-group mappings in theView-based Access Control Model (VACM). |
|
| |
| RFC 6066 | Transport Layer Security (TLS) Extensions: Extension Definitions |
| |
|
|
This document provides specifications for existing TLS extensions.It is a companion document for RFC 5246, "The Transport LayerSecurity (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. |
|
| |
| RFC 6067 | BCP 47 Extension U |
| |
| Authors: | M. Davis, A. Phillips, Y. Umaoka. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6067 |
|
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. |
|
| |
| RFC 6068 | The 'mailto' URI Scheme |
| |
| Authors: | M. Duerst, L. Masinter, J. Zawinski. |
| Date: | October 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 2368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6068 |
|
This document defines the format of Uniform Resource Identifiers(URIs) to identify resources that are reached using Internet mail.It adds better internationalization and compatibility withInternationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). |
|
| |
| RFC 6069 | Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) |
| |
| Authors: | A. Zimmermann, A. Hannemann. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6069 |
|
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs.This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. |
|
| |
| RFC 6070 | PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors |
| |
| Authors: | S. Josefsson. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6070 |
|
This document contains test vectors for the Public-Key CryptographyStandards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure HashAlgorithm (SHA-1) pseudorandom function. |
|
| |
| RFC 6071 | IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap |
| |
| Authors: | S. Frankel, S. Krishnan. |
| Date: | February 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 2411 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6071 |
|
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IPSecurity Document Roadmap."
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents.The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. |
|
| |
| RFC 6072 | Certificate Management Service for the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Jennings, J. Fischl, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6072 |
|
This document defines a credential service that allows SessionInitiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record(AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. |
|
| |
| RFC 6073 | Segmented Pseudowire |
| |
| Authors: | L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6723, RFC 7267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6073 |
|
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. |
|
| |
| RFC 6074 | Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) |
| |
| Authors: | E. Rosen, B. Davie, V. Radoaca, W. Luo. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6074 |
|
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a"discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN.This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). |
|
| |
| RFC 6075 | The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry |
| |
|
|
The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols.This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. |
|
| |
| RFC 6076 | Basic Telephony SIP End-to-End Performance Metrics |
| |
| Authors: | D. Malas, A. Morton. |
| Date: | January 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6076 |
|
This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. |
|
| |
| RFC 6077 | Open Research Issues in Internet Congestion Control |
| |
| Authors: | D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6077 |
|
This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. |
|
| |
| RFC 6078 | Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) |
| |
| Authors: | G. Camarillo, J. Melen. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6078 |
|
This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. |
|
| |
| RFC 6079 | HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) |
| |
| Authors: | G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6079 |
|
This document specifies a framework to build HIP-based (Host IdentityProtocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". |
|
| |
| RFC 6080 | A Framework for Session Initiation Protocol User Agent Profile Delivery |
| |
| Authors: | D. Petrie, S. Channabasappa, Ed.. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6080 |
|
This document specifies a framework to enable configuration ofSession Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. |
|
| |
| RFC 6081 | Teredo Extensions |
| |
|
|
This document specifies a set of extensions to the Teredo protocol.These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. |
|
| |
| RFC 6082 | Deprecating Unicode Language Tag Characters: RFC 2482 is Historic |
| |
| Authors: | K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 2482 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6082 |
|
RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. |
|
| |
| RFC 6083 | Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Seggelmann, E. Rescorla. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6083 |
|
This document describes the usage of the Datagram Transport LayerSecurity (DTLS) protocol over the Stream Control TransmissionProtocol (SCTP).
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. |
|
| |
| RFC 6084 | General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | X. Fu, C. Dickmann, J. Crowcroft. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6084 |
|
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over theStream Control Transmission Protocol (SCTP) and Datagram TransportLayer Security (DTLS). |
|
| |
| RFC 6085 | Address Mapping of IPv6 Multicast Packets on Ethernet |
| |
| Authors: | S. Gundavelli, M. Townsley, O. Troan, W. Dec. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updates: | RFC 2464 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6085 |
|
When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link- layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. |
|
| |
| RFC 6086 | Session Initiation Protocol (SIP) INFO Method and Package Framework |
| |
| Authors: | C. Holmberg, E. Burger, H. Kaplan. |
| Date: | January 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 2976 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6086 |
|
This document defines a method, INFO, for the Session InitiationProtocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. |
|
| |
| RFC 6087 | Guidelines for Authors and Reviewers of YANG Data Model Documents |
| |
|
|
This memo provides guidelines for authors and reviewers of StandardsTrack specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NetworkConfiguration Protocol (NETCONF) implementations that utilize YANG data model modules. |
|
| |
| RFC 6088 | Traffic Selectors for Flow Bindings |
| |
| Authors: | G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6088 |
|
This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for MobileIPv6. |
|
| |
| RFC 6089 | Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support |
| |
| Authors: | G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updates: | RFC 5648 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6089 |
|
This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. |
|
| |
| RFC 6090 | Fundamental Elliptic Curve Cryptography Algorithms |
| |
| Authors: | D. McGrew, K. Igoe, M. Salter. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6090 |
|
This note describes the fundamental algorithms of Elliptic CurveCryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. |
|
| |
| RFC 6091 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
| Authors: | N. Mavrogiannopoulos, D. Gillmor. |
| Date: | February 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 5081 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6091 |
|
This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. |
|
| |
| RFC 6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service |
| |
| Authors: | J. Woodyatt, Ed.. |
| Date: | January 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6092 |
|
This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks inInternet-enabled homes and small offices. |
|
| |
| RFC 6093 | On the Implementation of the TCP Urgent Mechanism |
| |
|
|
This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications(but provides advice to applications that do). |
|
| |
| RFC 6094 | Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols |
| |
| Authors: | M. Bhatia, V. Manral. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6094 |
|
The routing protocols Open Shortest Path First version 2 (OSPFv2),Intermediate System to Intermediate System (IS-IS), and RoutingInformation Protocol (RIP) currently define cleartext and MD5(Message Digest 5) methods for authenticating protocol packets.Recently, effort has been made to add support for the SHA (SecureHash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.
To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.
Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.
This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. |
|
| |
| RFC 6095 | Extending YANG with Language Abstractions |
| |
| Authors: | B. Linowski, M. Ersue, S. Kuryla. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6095 |
|
YANG -- the Network Configuration Protocol (NETCONF) Data ModelingLanguage -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancingYANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. |
|
| |
| RFC 6096 | Stream Control Transmission Protocol (SCTP) Chunk Flags Registration |
| |
|
|
This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream ControlTransmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. |
|
| |
| RFC 6097 | Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 |
| |
| Authors: | J. Korhonen, V. Devarapalli. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6097 |
|
Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to aProxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in theMobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. |
|
| |
| RFC 6098 | Generic Notification Message for Mobile IPv4 |
| |
| Authors: | H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6098 |
|
This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using aMobile IPv4 message type designed for this purpose. |
|
