| |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This document defines the XML schema of the vCard data format. |
|
| |
| RFC 6352 | CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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. |
|
