Internet Documents

RFCs 6300 - 6399s

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

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 6301 A Survey of Mobility Support in the Internet
 
Authors:Z. Zhu, R. Wakikawa, L. Zhang.
Date:July 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6301
Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale.
 
RFC 6302 Logging Recommendations for Internet-Facing Servers
 
Authors:A. Durand, I. Gashinsky, D. Lee, S. Sheppard.
Date:June 2011
Formats:txt json html
Also:BCP 0162
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6302
In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address.
 
RFC 6303 Locally Served DNS Zones
 
Authors:M. Andrews.
Date:July 2011
Formats:txt json html
Also:BCP 0163
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6303
Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise.RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC1918 address space and other well-known zones with similar characteristics.
 
RFC 6304 AS112 Nameserver Operations
 
Authors:J. Abley, W. Maton.
Date:July 2011
Formats:txt html json
Obsoleted by:RFC 7534
Status:INFORMATIONAL
DOI:10.17487/RFC 6304
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

 
RFC 6305 I'm Being Attacked by PRISONER.IANA.ORG!
 
Authors:J. Abley, W. Maton.
Date:July 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6305
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected.Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.

This document provides background information and technical advice to those firewall operators.

 
RFC 6306 Hierarchical IPv4 Framework
 
Authors:P. Frejborg.
Date:July 2011
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 6306
This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique.In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing DomainName System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers.

 
RFC 6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks
 
Authors:D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon.
Date:April 2012
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6307
A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service.
 
RFC 6308 Overview of the Internet Multicast Addressing Architecture
 
Authors:P. Savola.
Date:June 2011
Formats:txt html json
Obsoletes:RFC 2908
Status:INFORMATIONAL
DOI:10.17487/RFC 6308
The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.
 
RFC 6309 IANA Rules for MIKEY (Multimedia Internet KEYing)
 
Authors:J. Arkko, A. Keranen, J. Mattsson.
Date:August 2011
Formats:txt html json
Obsoletes:RFC 4909
Updates:RFC 3830, RFC 4563, RFC 5410, RFC 6043
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6309
This document clarifies and relaxes the IANA rules for MultimediaInternet KEYing (MIKEY). This document updates RFCs 3830, 4563,5410, and 6043; it obsoletes RFC 4909.
 
RFC 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping
 
Authors:M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein.
Date:July 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6310
This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior ofProvider Edges (PEs) with respect to PW and AC defects. It addressesATM, Frame Relay, Time Division Multiplexing (TDM), and SynchronousOptical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs).
 
RFC 6311 Protocol Support for High Availability of IKEv2/IPsec
 
Authors:R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang.
Date:July 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6311
The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsecHigh Availability (HA) clusters. However, there are many issues inIPsec HA clustering, and in particular in Internet Key ExchangeProtocol version 2 (IKEv2) clustering. An earlier document, "IPsecCluster Problem Statement", enumerates the issues encountered in theIKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization ofIKEv2 Message ID counters, and of IPsec replay counters.

 
RFC 6312 Mobile Networks Considerations for IPv6 Deployment
 
Authors:R. Koodli.
Date:July 2011
Formats:txt json html
Obsoleted by:RFC 6342
Status:INFORMATIONAL
DOI:10.17487/RFC 6312
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.
 
RFC 6313 Export of Structured Data in IP Flow Information Export (IPFIX)
 
Authors:B. Claise, G. Dhandapani, P. Aitken, S. Yates.
Date:July 2011
Formats:txt json html
Updates:RFC 5102
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6313
This document specifies an extension to the IP Flow InformationExport (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record.
 
RFC 6314 NAT Traversal Practices for Client-Server SIP
 
Authors:C. Boulton, J. Rosenberg, G. Camarillo, F. Audet.
Date:July 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6314
Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.
 
RFC 6315 IANA Registration for Enumservice 'iax'
 
Authors:E. Guy, K. Darilion.
Date:July 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6315
This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC6117.
 
RFC 6316 Sockets Application Program Interface (API) for Multihoming Shim
 
Authors:M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed..
Date:July 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6316
This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.

This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and theHost Identity Protocol (HIP).

 
RFC 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP)
 
Authors:M. Komu, T. Henderson.
Date:July 2011
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 6317
This document defines extensions to the current sockets API for theHost Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags(HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies.
 
RFC 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
 
Authors:R. Housley, J. Solinas.
Date:June 2011
Formats:txt html json
Obsoletes:RFC 5008
Status:HISTORIC
DOI:10.17487/RFC 6318
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008.
 
RFC 6319 Issues Associated with Designating Additional Private IPv4 Address Space
 
Authors:M. Azinger, L. Vegoda.
Date:July 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6319
When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of privateIPv4 address space.

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered.

 
RFC 6320 Protocol for Access Node Control Mechanism in Broadband Networks
 
Authors:S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed..
Date:October 2011
Formats:txt html json
Updated by:RFC 7256
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6320
This document describes the Access Node Control Protocol (ANCP).ANCP operates between a Network Access Server (NAS) and an AccessNode (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the baseANCP protocol, this document specifies capabilities for DigitalSubscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3(GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it.

 
RFC 6321 xCal: The XML Format for iCalendar
 
Authors:C. Daboo, M. Douglass, S. Lees.
Date:August 2011
Formats:txt html json
Updated by:RFC 6868, RFC 7529
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6321
This specification defines "xCal", an XML format for iCalendar data.
 
RFC 6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams
 
Authors:P. Hoffman.
Date:July 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6322
This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent SubmissionsEditor. The states and annotations that are to be added to theDatatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventualRFC, and will continue through the lifetime of the Internet-Draft.The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of theseInternet-Drafts and the streams from which they originate.
 
RFC 6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)
 
Authors:G. Renker, G. Fairhurst.
Date:July 2011
Formats:txt json html
Updates:RFC 4342, RFC 5622
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6323
This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol(DCCP). It updates specifications for the CCID-3 and CCID-4Congestion Control IDs of DCCP.

The update addresses parameter-estimation problems occurring withTFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

It is integrated into the feature set of DCCP as an end-to-end negotiable extension.

 
RFC 6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
 
Authors:G. Nakibly, F. Templin.
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6324
This document is concerned with security vulnerabilities in IPv6-in-IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration.
 
RFC 6325 Routing Bridges (RBridges): Base Protocol Specification
 
Authors:R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani.
Date:July 2011
Formats:txt html json
Updated by:RFC 6327, RFC 6439, RFC 7172, RFC 7177, RFC 7357, RFC 7179, RFC 7180, RFC 7455, RFC 7780, RFC 7783, RFC 8139, RFC 8249, RFC 8361, RFC 8377
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6325
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges(rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges.

 
RFC 6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
 
Authors:D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani.
Date:July 2011
Formats:txt json html
Obsoleted by:RFC 7176
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6326
The IETF has standardized the Transparent Interconnection of Lots ofLinks (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.This document specifies the data formats and code points for theIS-IS extensions to support TRILL.
 
RFC 6327 Routing Bridges (RBridges): Adjacency
 
Authors:D. Eastlake 3rd, R. Perlman, A. Ghanwani, D. Dutt, V. Manral.
Date:July 2011
Formats:txt json html
Obsoleted by:RFC 7177
Updates:RFC 6325
Updated by:RFC 7180
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6327
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU(Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.

 
RFC 6328 IANA Considerations for Network Layer Protocol Identifiers
 
Authors:D. Eastlake 3rd.
Date:July 2011
Formats:txt html json
Also:BCP 0164
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6328
Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization /International Electrotechnical Commission) Network Layer ProtocolIdentifier (NLPID). This document provides NLPID IANA considerations.
 
RFC 6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
 
Authors:D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen.
Date:April 2012
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6329
802.1aq Shortest Path Bridging (SPB) has been standardized by theIEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples.
 
RFC 6330 RaptorQ Forward Error Correction Scheme for Object Delivery
 
Authors:M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder.
Date:August 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6330
This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated.

 
RFC 6331 Moving DIGEST-MD5 to Historic
 
Authors:A. Melnikov.
Date:July 2011
Formats:txt html json
Obsoletes:RFC 2831
Status:INFORMATIONAL
DOI:10.17487/RFC 6331
This memo describes problems with the DIGEST-MD5 SimpleAuthentication and Security Layer (SASL) mechanism as specified inRFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry ofSASL mechanisms and moves RFC 2831 to Historic status.
 
RFC 6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
 
Authors:A. Begen, E. Friedrich.
Date:July 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6332
In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies.Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called theMulticast Acquisition (MA) report block, within the framework of RTPControl Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).
 
RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
 
Authors:A. Durand, R. Droms, J. Woodyatt, Y. Lee.
Date:August 2011
Formats:txt json html
Updated by:RFC 7335
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6333
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT).
 
RFC 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite
 
Authors:D. Hankins, T. Mrugalski.
Date:August 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6334
This document specifies a DHCPv6 option that is meant to be used by aDual-Stack Lite Basic Bridging BroadBand (B4) element to discover theIPv6 address of its corresponding Address Family Transition Router(AFTR).
 
RFC 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
 
Authors:M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire.
Date:August 2011
Formats:txt html json
Updates:RFC 2780, RFC 2782, RFC 3828, RFC 4340, RFC 4960, RFC 5595
Also:BCP 0165
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6335
This document defines the procedures that the Internet AssignedNumbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol PortNumber registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.

This document updates IANA's procedures by obsoleting the previousUDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the DatagramCongestion Control Protocol (DCCP), and the Stream ControlTransmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered.

 
RFC 6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options
 
Authors:M. Westerlund, C. Perkins.
Date:July 2011
Formats:txt json html
Obsoleted by:RFC 8839
Updates:RFC 5245
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6336
It has been identified that "Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator (NAT) Traversal forOffer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245.
 
RFC 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
 
Authors:S. Okumura, T. Sawada, P. Kyzivat.
Date:August 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6337
The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the SessionDescription Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication.
 
RFC 6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)
 
Authors:V. Giralt, R. McDuff.
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6338
This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).

The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes.

 
RFC 6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)
 
Authors:S. Josefsson, L. Hornquist Astrand.
Date:August 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6339
This document describes three abstract Generic Security ServiceApplication Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces.
 
RFC 6340 Textual Conventions for the Representation of Floating-Point Numbers
 
Authors:R. Presuhn.
Date:August 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6340
This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers.
 
RFC 6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
 
Authors:K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain.
Date:August 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6341
Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.

Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based MediaRecording.

 
RFC 6342 Mobile Networks Considerations for IPv6 Deployment
 
Authors:R. Koodli.
Date:August 2011
Formats:txt html json
Obsoletes:RFC 6312
Status:INFORMATIONAL
DOI:10.17487/RFC 6342
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.
 
RFC 6343 Advisory Guidelines for 6to4 Deployment
 
Authors:B. Carpenter.
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6343
This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to ContentProviders. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls.
 
RFC 6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
 
Authors:G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort.
Date:August 2011
Formats:txt json html
Updates:RFC 4606
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6344
This document describes requirements for, and the use of, theGeneralized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link CapacityAdjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply toOptical Transport Network (OTN), Synchronous Optical Network (SONET),Synchronous Digital Hierarchy (SDH), and Plesiochronous DigitalHierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation.
 
RFC 6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element
 
Authors:P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin.
Date:August 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6345
This document specifies Protocol for carrying Authentication forNetwork Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent(PAA) where the two nodes cannot reach each other by means of regularIP routing.
 
RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage
 
Authors:R. Bush, Ed..
Date:August 2011
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 6346
We are facing the exhaustion of the IANA IPv4 free IP address pool.Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face ofIPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.

 
RFC 6347 Datagram Transport Layer Security Version 1.2
 
Authors:E. Rescorla, N. Modadugu.
Date:January 2012
Formats:txt html json
Obsoletes:RFC 4347
Obsoleted by:RFC 9147
Updated by:RFC 7507, RFC 7905, RFC 8996, RFC 9146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6347
This document specifies version 1.2 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updatesDTLS 1.0 to work with TLS version 1.2.
 
RFC 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol
 
Authors:JL. Le Roux, Ed., T. Morin, Ed..
Date:September 2011
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 6348
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over aMultiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by theMPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work.

 
RFC 6349 Framework for TCP Throughput Testing
 
Authors:B. Constantine, G. Forget, R. Geib, R. Schrage.
Date:August 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6349
This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCPThroughput.
 
RFC 6350 vCard Format Specification
 
Authors:S. Perreault.
Date:August 2011
Formats:txt json html
Obsoletes:RFC 2425, RFC 2426, RFC 4770
Updates:RFC 2739
Updated by:RFC 6868, RFC 9554, RFC 9555
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6350
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.
 
RFC 6351 xCard: vCard XML Representation
 
Authors:S. Perreault.
Date:August 2011
Formats:txt json html
Updated by:RFC 6868
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6351
This document defines the XML schema of the vCard data format.
 
RFC 6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
 
Authors:C. Daboo.
Date:August 2011
Formats:txt html json
Updated by:RFC 6764
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6352
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format.
 
RFC 6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
 
Authors:W. Hardaker.
Date:July 2011
Formats:txt html json
Obsoletes:RFC 5953
Updated by:RFC 8996, RFC 9456
Also:STD 0078
Status:INTERNET STANDARD
DOI:10.17487/RFC 6353
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of anSNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.

 
RFC 6354 Forward-Shifted RTP Redundancy Payload Support
 
Authors:Q. Xie.
Date:August 2011
Formats:txt json html
Updates:RFC 2198, RFC 4102
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6354
This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media).
 
RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
 
Authors:T. Narten, J. Johnson.
Date:August 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6355
This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already- standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves toDHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP.
 
RFC 6356 Coupled Congestion Control for Multipath Transport Protocols
 
Authors:C. Raiciu, M. Handley, D. Wischik.
Date:October 2011
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 6356
Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links.

 
RFC 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control
 
Authors:V. Hilt, E. Noel, C. Shen, A. Abdelal.
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6357
Overload occurs in Session Initiation Protocol (SIP) networks whenSIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism.
 
RFC 6358 Additional Master Secret Inputs for TLS
 
Authors:P. Hoffman.
Date:January 2012
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 6358
This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS(DTLS).
 
RFC 6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information
 
Authors:S. Ginoza, M. Cotton, A. Morris.
Date:September 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6359
This document captures the requirements for integrating IANA and RFCEditor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC.Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible.
 
RFC 6360 Conclusion of FYI RFC Sub-Series
 
Authors:R. Housley.
Date:August 2011
Formats:txt json html
Obsoletes:RFC 1150
Status:INFORMATIONAL
DOI:10.17487/RFC 6360
This document concludes the For Your Information (FYI) sub-series ofRFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic.
 
RFC 6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
 
Authors:J. Carlson, D. Eastlake 3rd.
Date:August 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6361
The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) viaPPP links.
 
RFC 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)
 
Authors:K. Meadors, Ed..
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6362
The Electronic Data Interchange - Internet Integration (EDIINT) AS1,AS2, and AS3 messages were designed specifically for the transport ofEDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided.
 
RFC 6363 Forward Error Correction (FEC) Framework
 
Authors:M. Watson, A. Begen, V. Roca.
Date:October 2011
Formats:txt html json
Updated by:RFC 8680
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6363
This document describes a framework for using Forward ErrorCorrection (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content DeliveryProtocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.
 
RFC 6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework
 
Authors:A. Begen.
Date:October 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6364
This document specifies the use of the Session Description Protocol(SDP) to describe the parameters required to signal the Forward ErrorCorrection (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework.
 
RFC 6365 Terminology Used in Internationalization in the IETF
 
Authors:P. Hoffman, J. Klensin.
Date:September 2011
Formats:txt json html
Obsoletes:RFC 3536
Also:BCP 0166
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6365
This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
 
RFC 6366 Requirements for an Internet Audio Codec
 
Authors:J. Valin, K. Vos.
Date:August 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6366
This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties.
 
RFC 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)
 
Authors:S. Kanno, M. Kanda.
Date:September 2011
Formats:txt html json
Updated by:RFC 8996
Status:INFORMATIONAL
DOI:10.17487/RFC 6367
This document specifies forty-two cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher.
 
RFC 6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
 
Authors:P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata.
Date:September 2011
Formats:txt json html
Updated by:RFC 7606, RFC 9494
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6368
This document defines protocol extensions and procedures for BGPProvider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned.
 
RFC 6369 Forwarding and Control Element Separation (ForCES) Implementation Experience
 
Authors:E. Haleplidis, O. Koufopavlou, S. Denazis.
Date:September 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6369
The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a ForwardingElement (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing theForCES protocol.
 
RFC 6370 MPLS Transport Profile (MPLS-TP) Identifiers
 
Authors:M. Bocci, G. Swallow, E. Gray.
Date:September 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6370
This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations,Administration, and Maintenance (OAM) functions compatible with IP/MPLS conventions.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
 
Authors:I. Busi, Ed., D. Allan, Ed..
Date:September 2011
Formats:txt json html
Updated by:RFC 6435
Status:INFORMATIONAL
DOI:10.17487/RFC 6371
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS TrafficEngineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set ofOperations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 6372 MPLS Transport Profile (MPLS-TP) Survivability Framework
 
Authors:N. Sprecher, Ed., A. Farrel, Ed..
Date:September 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6372
Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources.Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements(SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.

This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance(OAM) functions. This document describes mechanisms for recoveringMPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.

 
RFC 6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework
 
Authors:L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed..
Date:September 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6373
The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management- plane functions are out of scope of this document.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 6374 Packet Loss and Delay Measurement for MPLS Networks
 
Authors:D. Frost, S. Bryant.
Date:September 2011
Formats:txt json html
Updated by:RFC 7214
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6374
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
 
RFC 6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks
 
Authors:D. Frost, Ed., S. Bryant, Ed..
Date:September 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6375
Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.

This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.

This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

 
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
 
Authors:D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed..
Date:September 2011
Formats:txt html json
Obsoletes:RFC 4871, RFC 5672
Updated by:RFC 8301, RFC 8463, RFC 8553, RFC 8616
Also:STD 0076
Status:INTERNET STANDARD
DOI:10.17487/RFC 6376
DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672.

 
RFC 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists
 
Authors:M. Kucherawy.
Date:September 2011
Formats:txt html json
Also:BCP 0167
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6377
DomainKeys Identified Mail (DKIM) allows an ADministrative ManagementDomain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers(MLMs).
 
RFC 6378 MPLS Transport Profile (MPLS-TP) Linear Protection
 
Authors:Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed..
Date:October 2011
Formats:txt json html
Updated by:RFC 7214, RFC 7271, RFC 7324
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6378
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationsStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TPSurvivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection StateCoordination for linear protection, as described in that document.

 
RFC 6379 Suite B Cryptographic Suites for IPsec
 
Authors:L. Law, J. Solinas.
Date:October 2011
Formats:txt json html
Obsoletes:RFC 4869
Status:HISTORIC
DOI:10.17487/RFC 6379
This document proposes four cryptographic user interface suites("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites.
 
RFC 6380 Suite B Profile for Internet Protocol Security (IPsec)
 
Authors:K. Burgin, M. Peck.
Date:October 2011
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 6380
The United States Government has published guidelines for "NSASuite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IPSecurity (IPsec).

Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B.

 
RFC 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types
 
Authors:R. Gellens, D. Singer, P. Frojdh.
Date:August 2011
Formats:txt json html
Obsoletes:RFC 4281
Updates:RFC 3839, RFC 4393, RFC 4337
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6381
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content-Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies.This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean.

 
RFC 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
 
Authors:D. McPherson, R. Donnelly, F. Scalzo.
Date:October 2011
Formats:txt html json
Also:BCP 0169
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6382
This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.
 
RFC 6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
 
Authors:K. Shiomoto, A. Farrel.
Date:September 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6383
The Resource Reservation Protocol (RSVP) has been extended to supportTraffic Engineering (TE) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.

End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.

This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices.

 
RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
 
Authors:I. van Beijnum.
Date:October 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6384
The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers,FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are stillIPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch.

 
RFC 6385 General Area Review Team (Gen-ART) Experiences
 
Authors:M. Barnes, A. Doria, H. Alvestrand, B. Carpenter.
Date:October 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6385
The General Area Review Team (Gen-ART) has been doing reviews ofInternet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF LastCall is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda.
 
RFC 6386 VP8 Data Format and Decoding Guide
 
Authors:J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu.
Date:November 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6386
This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format.
 
RFC 6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
 
Authors:A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric.
Date:September 2011
Formats:txt html json
Obsoletes:RFC 5467
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6387
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467.
 
RFC 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
 
Authors:IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas.
Date:November 2011
Formats:txt json html
Updated by:RFC 7358
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6388
This document describes extensions to the Label Distribution Protocol(LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.These extensions are also referred to as multipoint LDP. MultipointLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks(L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document.
 
RFC 6389 MPLS Upstream Label Assignment for LDP
 
Authors:R. Aggarwal, JL. Le Roux.
Date:November 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6389
This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label SwitchingRouter (LSR) traffic replication on a LAN for LDP point-to-multipoint(P2MP) Label Switched Paths (LSPs).
 
RFC 6390 Guidelines for Considering New Performance Metric Development
 
Authors:A. Clark, B. Claise.
Date:October 2011
Formats:txt json html
Also:BCP 0170
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6390
This document describes a framework and a process for developingPerformance Metrics of protocols and applications transported overIETF-specified protocols. These metrics can be used to characterize traffic on live networks and services.
 
RFC 6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
 
Authors:S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante.
Date:November 2011
Formats:txt json html
Updated by:RFC 7274
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6391
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal CostMultiple Paths (ECMPs) that exist in the packet switched network.Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires.The mechanism uses an additional label in the MPLS label stack.

 
RFC 6392 A Survey of In-Network Storage Systems
 
Authors:R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed..
Date:October 2011
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 6392
This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupledApplication Data Enroute) architecture.
 
RFC 6393 Moving RFC 4693 to Historic
 
Authors:M. Yevstifeyev.
Date:September 2011
Formats:txt html json
Obsoletes:RFC 4693
Status:INFORMATIONAL
DOI:10.17487/RFC 6393
This document moves RFC 4693 to Historic status. It also obsoletesRFC 4693.
 
RFC 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
 
Authors:R. Barnes.
Date:October 2011
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 6394
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name.Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSecurity Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names.
 
RFC 6395 An Interface Identifier (ID) Hello Option for PIM
 
Authors:S. Gulrajani, S. Venaas.
Date:October 2011
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6395
This document defines a new PIM Hello option to advertise anInterface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router.
 
RFC 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
 
Authors:L. Blunk, M. Karir, C. Labovitz.
Date:October 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6396
This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threadedRouting Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents.
 
RFC 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions
 
Authors:T. Manderson.
Date:October 2011
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 6397
This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers.
 
RFC 6398 IP Router Alert Considerations and Usage
 
Authors:F. Le Faucheur, Ed..
Date:October 2011
Formats:txt json html
Updates:RFC 2113, RFC 2711
Also:BCP 0168
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 6398
The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. TheResource reSerVation Protocol (RSVP), Pragmatic General Multicast(PGM), the Internet Group Management Protocol (IGMP), MulticastListener Discovery (MLD), Multicast Router Discovery (MRD), andGeneral Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the currentIP Router Alert Option, thereby updating RFC 2113 and RFC 2711.Specifically, it provides recommendations against using the RouterAlert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines forRouter Alert implementation on routers.