Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 6000 - 6099s

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

 
RFC 6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
 
Authors:D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux.
Date:October 2010
Formats:txt pdf
Updates:RFC 4202, RFC 4203, RFC 4206, RFC 4874, RFC 4974, RFC 5307
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6001
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
 
Authors:L. Berger, D. Fedyk.
Date:October 2010
Formats:txt pdf
Updates:RFC 3471, RFC 3473, RFC 3945, RFC 4202, RFC 4203, RFC 5307
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6002
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
 
Authors:D. Papadimitriou.
Date:October 2010
Formats:txt pdf
Updates:RFC 3471, RFC 3473
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6003
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Salowey, T. Petch, R. Gerhards, H. Feng.
Date:October 2010
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6012
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)
 
Authors:W. Simpson.
Date:January 2011
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 6013
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
 
Authors:P. Hoffman.
Date:November 2010
Formats:txt pdf
Updates:RFC 4033, RFC 4034, RFC 4035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6014
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:R. Housley.
Date:September 2010
Formats:txt pdf
Obsoletes:RFC 4049
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6019
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:S. Turner.
Date:December 2010
Formats:txt pdf
Updated by:RFC 6161
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6033
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:B. Briscoe.
Date:November 2010
Formats:txt pdf
Updates:RFC 3168, RFC 4301, RFC 4774
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6040
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 pdf
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
 
Authors:A. Keromytis.
Date:October 2010
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 6042
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)
 
Authors:J. Mattsson, T. Tian.
Date:March 2011
Formats:txt pdf
Updated by:RFC 6309
Status:INFORMATIONAL
DOI:10.17487/RFC 6043
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)
 
Authors:M. Mohali.
Date:October 2010
Formats:txt pdf
Obsoleted by:RFC 7544
Status:INFORMATIONAL
DOI:10.17487/RFC 6044
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)
 
Authors:K. Moriarty.
Date:November 2010
Formats:txt pdf
Obsoleted by:RFC 6545
Status:INFORMATIONAL
DOI:10.17487/RFC 6045
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 pdf
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)
 
Authors:A. Melnikov, Ed..
Date:December 2010
Formats:txt pdf
Obsoletes:RFC 2447
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6047
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
 
Authors:J. Elie.
Date:November 2010
Formats:txt pdf
Updates:RFC 2980, RFC 3977
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6048
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:M. Larsen, F. Gont.
Date:January 2011
Formats:txt pdf
Also:BCP 0156
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6056
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 pdf
Status:INFORMATIONAL
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:D. Eastlake 3rd.
Date:January 2011
Formats:txt pdf
Obsoletes:RFC 4366
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6066
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:D. Cridland.
Date:December 2010
Formats:txt pdf
Updates:RFC 2244
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6075
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:D. Thaler.
Date:January 2011
Formats:txt pdf
Updates:RFC 4380
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6081
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:A. Bierman.
Date:January 2011
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 6087
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:F. Gont, A. Yourtchenko.
Date:January 2011
Formats:txt pdf
Updates:RFC 0793, RFC 1011, RFC 1122
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6093
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 pdf
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 pdf
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
 
Authors:M. Tuexen, R. Stewart.
Date:January 2011
Formats:txt pdf
Updates:RFC 4960
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6096
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 pdf
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 pdf
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.