| |
| RFC 6601 | Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks |
| |
| Authors: | G. Ash, Ed., D. McDysan. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6601 |
|
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv- aware MPLS Traffic Engineering (DS-TE), Path Computation Element(PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLSGCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. |
|
| |
| RFC 6602 | Bulk Binding Update Support for Proxy Mobile IPv6 |
| |
| Authors: | F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6602 |
|
For extending the lifetime of a mobility session, the Proxy MobileIPv6 specification requires the mobile access gateway to send a ProxyBinding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. |
|
| |
| RFC 6603 | Prefix Exclude Option for DHCPv6-based Prefix Delegation |
| |
| Authors: | J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan. |
| Date: | May 2012 |
| Formats: | txt html json |
| Updates: | RFC 3633 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6603 |
|
This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when usingDHCPv6-based prefix delegation. The new mechanism updates RFC 3633. |
|
| |
| RFC 6604 | xNAME RCODE and Status Bits Clarification |
| |
|
|
The Domain Name System (DNS) has long provided means, such as theCNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how theRCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. |
|
| |
| RFC 6605 | Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC |
| |
| Authors: | P. Hoffman, W.C.A. Wijngaards. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6605 |
|
This document describes how to specify Elliptic Curve DigitalSignature Algorithm (DSA) keys and signatures in DNS Security(DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. |
|
| |
| RFC 6606 | Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing |
| |
| Authors: | E. Kim, D. Kaspar, C. Gomez, C. Bormann. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6606 |
|
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
This document provides the problem statement and design space for6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETFROLL WG. |
|
| |
| RFC 6607 | Virtual Subnet Selection Options for DHCPv4 and DHCPv6 |
| |
| Authors: | K. Kinnear, R. Johnson, M. Stapp. |
| Date: | April 2012 |
| Formats: | txt html json |
| Updates: | RFC 3046 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6607 |
|
This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, aDHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place.
For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of sub- options (see Section 8). |
|
| |
| RFC 6608 | Subcodes for BGP Finite State Machine Error |
| |
| Authors: | J. Dong, M. Chen, A. Suryanarayana. |
| Date: | May 2012 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6608 |
|
This document defines several subcodes for the BGP Finite StateMachine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. |
|
| |
| RFC 6609 | Sieve Email Filtering: Include Extension |
| |
| Authors: | C. Daboo, A. Stone. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6609 |
|
The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. |
|
| |
| RFC 6610 | DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) |
| |
| Authors: | H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6610 |
|
This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. |
|
| |
| RFC 6611 | Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario |
| |
| Authors: | K. Chowdhury, Ed., A. Yegin. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6611 |
|
Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. |
|
| |
| RFC 6612 | Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues |
| |
| Authors: | G. Giaretta, Ed.. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6612 |
|
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. |
|
| |
| RFC 6613 | RADIUS over TCP |
| |
|
|
The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over theTransmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security(RADIUS/TLS). It permits TCP to be used as a transport protocol forRADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. |
|
| |
| RFC 6614 | Transport Layer Security (TLS) Encryption for RADIUS |
| |
| Authors: | S. Winter, M. McCauley, S. Venaas, K. Wierenga. |
| Date: | May 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6614 |
|
This document specifies a transport profile for RADIUS usingTransport Layer Security (TLS) over TCP as the transport protocol.This enables dynamic trust relationships between RADIUS servers. |
|
| |
| RFC 6615 | Definitions of Managed Objects for IP Flow Information Export |
| |
| Authors: | T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. |
| Date: | June 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 5815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6615 |
|
This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors, including basic configuration information. |
|
| |
| RFC 6616 | A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID |
| |
| Authors: | E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6616 |
|
OpenID has found its usage on the Internet for Web Single Sign-On.Simple Authentication and Security Layer (SASL) and the GenericSecurity Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. |
|
| |
| RFC 6617 | Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | D. Harkins. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6617 |
|
This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. |
|
| |
| RFC 6618 | Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent |
| |
| Authors: | J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6618 |
|
Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent(HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol(IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the MobileIPv6 protocol component and the IKE/IPsec module of the IP stack.This document proposes an alternate security framework for MobileIPv6 and Dual-Stack Mobile IPv6, which relies on Transport LayerSecurity for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA. |
|
| |
| RFC 6619 | Scalable Operation of Address Translators with Per-Interface Bindings |
| |
| Authors: | J. Arkko, L. Eggert, M. Townsley. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6619 |
|
This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. |
|
| |
| RFC 6620 | FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses |
| |
| Authors: | E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6620 |
|
This memo describes First-Come, First-Served Source AddressValidation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. |
|
| |
| RFC 6621 | Simplified Multicast Forwarding |
| |
| Authors: | J. Macker, Ed.. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6621 |
|
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection(DPD), to be applied in the forwarding process, for both IPv4 andIPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicastMANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. |
|
| |
| RFC 6622 | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | U. Herberg, T. Clausen. |
| Date: | May 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6622 |
|
This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. |
|
| |
| RFC 6623 | IANA Registry for MEDIACTRL Interactive Voice Response Control Package |
| |
|
|
This document creates an IANA registry for the response codes for theMEDIACTRL Interactive Voice Response Control Package, as described inRFC 6231. |
|
| |
| RFC 6624 | Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling |
| |
| Authors: | K. Kompella, B. Kothari, R. Cherukuri. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6624 |
|
Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular.Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IPVPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. |
|
| |
| RFC 6625 | Wildcards in Multicast VPN Auto-Discovery Routes |
| |
|
|
In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network.The base specifications for MVPN define BGP multicast VPN "auto- discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto- discovery route can refer to multiple customer flows or even to all customer flows. |
|
| |
| RFC 6626 | Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) |
| |
| Authors: | G. Tsirtsis, V. Park, V. Narayanan, K. Leung. |
| Date: | May 2012 |
| Formats: | txt html json |
| Updates: | RFC 5177 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6626 |
|
The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism forNEMOv4. |
|
| |
| RFC 6627 | Overview of Pre-Congestion Notification Encoding |
| |
| Authors: | G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6627 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion.
The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. |
|
| |
| RFC 6628 | Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 |
| |
| Authors: | S. Shin, K. Kobara. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6628 |
|
This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). |
|
| |
| RFC 6629 | Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) |
| |
| Authors: | J. Abley, M. Bagnulo, A. Garcia-Martinez. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6629 |
|
This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. |
|
| |
| RFC 6630 | EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) |
| |
| Authors: | Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6630 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.
Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or moreCandidate Attachment Points (CAPs) prior to handover. AAK uses theAAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK support in ERP. |
|
| |
| RFC 6631 | Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) |
| |
| Authors: | D. Kuegler, Y. Sheffer. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6631 |
|
The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password- authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. |
|
| |
| RFC 6632 | An Overview of the IETF Network Management Standards |
| |
| Authors: | M. Ersue, Ed., B. Claise. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6632 |
|
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETFStandards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other StandardDevelopment Organizations or bodies planning to use IETF management technologies and data models. This document does not coverOperations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP)OAM, and pseudowire as well as the corresponding management models. |
|
| |
| RFC 6633 | Deprecation of ICMP Source Quench Messages |
| |
|
|
This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. |
|
| |
| RFC 6635 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620, and obsoletes that document. |
|
| |
| RFC 6636 | Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks |
| |
| Authors: | H. Asaeda, H. Liu, Q. Wu. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6636 |
|
The Internet Group Management Protocol (IGMP) and Multicast ListenerDiscovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other.This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. |
|
| |
| RFC 6637 | Elliptic Curve Cryptography (ECC) in OpenPGP |
| |
|
|
This document defines an Elliptic Curve Cryptography extension to theOpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. |
|
| |
| RFC 6638 | Scheduling Extensions to CalDAV |
| |
|
|
This document defines extensions to the Calendaring Extensions toWebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. |
|
| |
| RFC 6639 | Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview |
| |
| Authors: | D. King, Ed., M. Venkatesan, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6639 |
|
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.
This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. |
|
| |
| RFC 6640 | IETF Meeting Attendees' Frequently Asked (Travel) Questions |
| |
| Authors: | W. George. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6640 |
|
This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in theIETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. |
|
| |
| RFC 6641 | Using DNS SRV to Specify a Global File Namespace with NFS Version 4 |
| |
| Authors: | C. Everhart, W. Adamson, J. Zhang. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6641 |
|
The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. |
|
| |
| RFC 6642 | RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report |
| |
| Authors: | Q. Wu, Ed., F. Xia, R. Even. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6642 |
|
In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SessionDescription Protocol (SDP) signaling is also defined. |
|
| |
| RFC 6643 | Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules |
| |
| Authors: | J. Schoenwaelder. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6643 |
|
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revisingMIB modules for use with the Simple Network Management Protocol(SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. |
|
| |
| RFC 6644 | Rebind Capability in DHCPv6 Reconfigure Messages |
| |
| Authors: | D. Evans, R. Droms, S. Jiang. |
| Date: | July 2012 |
| Formats: | txt html json |
| Updates: | RFC 3315 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6644 |
|
This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. |
|
| |
| RFC 6645 | IP Flow Information Accounting and Export Benchmarking Methodology |
| |
| Authors: | J. Novak. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6645 |
|
This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow InformationExport". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. |
|
| |
| RFC 6646 | DECoupled Application Data Enroute (DECADE) Problem Statement |
| |
| Authors: | H. Song, N. Zong, Y. Yang, R. Alimi. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6646 |
|
Peer-to-peer (P2P) applications have become widely used on theInternet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. |
|
| |
| RFC 6647 | Email Greylisting: An Applicability Statement for SMTP |
| |
| Authors: | M. Kucherawy, D. Crocker. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6647 |
|
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. |
|
| |
| RFC 6648 | Deprecating the "X-" Prefix and Similar Constructs in Application Protocols |
| |
| Authors: | P. Saint-Andre, D. Crocker, M. Nottingham. |
| Date: | June 2012 |
| Formats: | txt html json |
| Also: | BCP 0178 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6648 |
|
Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual(as opposed to numerical) names in application protocols. |
|
| |
| RFC 6649 | Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos |
| |
|
|
The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the NationalInstitute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average.DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms inKerberos. Because RFC 1510 (obsoleted by RFC 4120) supports onlyDES, this document recommends the reclassification of RFC 1510 asHistoric. |
|
| |
| RFC 6650 | Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) |
| |
| Authors: | J. Falk, M. Kucherawy, Ed.. |
| Date: | June 2012 |
| Formats: | txt html json |
| Updates: | RFC 5965 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6650 |
|
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. |
|
| |
| RFC 6651 | Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting |
| |
| Authors: | M. Kucherawy. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6651 |
|
This document presents extensions to the DomainKeys Identified Mail(DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. |
|
| |
| RFC 6652 | Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format |
| |
|
|
This memo presents extensions to the Abuse Reporting Format (ARF) andSender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.
This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. |
|
| |
| RFC 6653 | DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks |
| |
| Authors: | B. Sarikaya, F. Xia, T. Lemon. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6653 |
|
As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 PrefixDelegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to aDHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting(AAA) servers. |
|
| |
| RFC 6654 | Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) |
| |
| Authors: | T. Tsou, C. Zhou, T. Taylor, Q. Chen. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6654 |
|
This document proposes an alternative IPv6 Rapid Deployment on IPv4Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator'sIPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. |
|
| |
| RFC 6655 | AES-CCM Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | D. McGrew, D. Bailey. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6655 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message AuthenticationCode (CBC-MAC) Mode (CCM) of operation within Transport LayerSecurity (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. |
|
| |
| RFC 6656 | Description of Cisco Systems' Subnet Allocation Option for DHCPv4 |
| |
| Authors: | R. Johnson, K. Kinnear, M. Stapp. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6656 |
|
This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the CiscoSystems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range128-223 should be documented and that the working group will try to officially assign those numbers to those options. |
|
| |
| RFC 6657 | Update to MIME regarding "charset" Parameter Handling in Textual Media Types |
| |
|
|
This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. |
|
| |
| RFC 6658 | Packet Pseudowire Encapsulation over an MPLS PSN |
| |
| Authors: | S. Bryant, Ed., L. Martini, G. Swallow, A. Malis. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6658 |
|
This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer3 protocols between the pair of client LSRs. |
|
| |
| RFC 6659 | Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method |
| |
| Authors: | A. Begen. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6659 |
|
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicastRTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. |
|
| |
| RFC 6660 | Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) |
| |
| Authors: | B. Briscoe, T. Moncaster, M. Menth. |
| Date: | July 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 5696 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6660 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.
This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked(NM), threshold-marked (ThM), and excess-traffic-marked (ETM).Hence, it is called the 3-in-1 PCN encoding. This document obsoletesRFC 5696. |
|
| |
| RFC 6661 | Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation |
| |
| Authors: | A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed.. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6661 |
|
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. |
|
| |
| RFC 6662 | Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation |
| |
| Authors: | A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed.. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6662 |
|
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. |
|
| |
| RFC 6663 | Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain |
| |
| Authors: | G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6663 |
|
Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN- domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the Decision Point; (2) the Decision Point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. TheDecision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors,Controlled Load (CL) and Single Marking (SM). |
|
| |
| RFC 6664 | S/MIME Capabilities for Public Key Definitions |
| |
| Authors: | J. Schaad. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6664 |
|
This document defines a set of Secure/Multipurpose Internet MailExtensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses."Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. |
|
| |
| RFC 6665 | SIP-Specific Event Notification |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. |
|
| |
| RFC 6666 | A Discard Prefix for IPv6 |
| |
| Authors: | N. Hilliard, D. Freedman. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6666 |
|
Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 SpecialPurpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitatingIPv6 remote triggered black hole filtering and routing. |
|
| |
| RFC 6667 | LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements |
| |
| Authors: | K. Raza, S. Boutros, C. Pignataro. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6667 |
|
The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a TypedWildcard FEC Element must be individually defined for each FECElement type. This specification defines the Typed Wildcard FECElements for the Pseudowire Identifier (PWid) (0x80) and GeneralizedPWid (0x81) FEC Element types. |
|
| |
| RFC 6668 | SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm. |
|
| |
| RFC 6669 | An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks |
| |
| Authors: | N. Sprecher, L. Fang. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6669 |
|
This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.This overview includes a brief recap of the MPLS Transport Profile(MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. |
|
| |
| RFC 6670 | The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | N. Sprecher, KY. Hong. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6670 |
|
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work onMPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
During the process of development of the profile, additions to theMPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.
One major set of additions provides enhanced support for Operations,Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. |
|
| |
| RFC 6671 | Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) |
| |
| Authors: | M. Betts. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6671 |
|
This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, andManagement (MPLS-TP OAM) messages in the MPLS Generic AssociatedChannel. |
|
| |
| RFC 6672 | DNAME Redirection in the DNS |
| |
|
|
The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). |
|
| |
| RFC 6673 | Round-Trip Packet Loss Metrics |
| |
| Authors: | A. Morton. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6673 |
|
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active MeasurementProtocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.
This memo adds round-trip loss to the set of IP Performance Metrics(IPPM). |
|
| |
| RFC 6674 | Gateway-Initiated Dual-Stack Lite Deployment |
| |
| Authors: | F. Brockners, S. Gundavelli, S. Speicher, D. Ward. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6674 |
|
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embeddedContext Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. |
|
| |
| RFC 6675 | A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP |
| |
| Authors: | E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida. |
| Date: | August 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3517 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6675 |
|
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. |
|
| |
| RFC 6676 | Multicast Addresses for Documentation |
| |
| Authors: | S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6676 |
|
This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use.Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. |
|
| |
| RFC 6677 | Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods |
| |
| Authors: | S. Hartman, Ed., T. Clancy, K. Hoeper. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6677 |
|
This document defines how to implement channel bindings forExtensible Authentication Protocol (EAP) methods to address the"lying Network Access Service (NAS)" problem as well as the "lying provider" problem. |
|
| |
| RFC 6678 | Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method |
| |
| Authors: | K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed.. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6678 |
|
This memo defines the requirements for a tunnel-based ExtensibleAuthentication Protocol (EAP) Method. This tunnel method will useTransport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. |
|
| |
| RFC 6679 | Explicit Congestion Notification (ECN) for RTP over UDP |
| |
| Authors: | M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. |
| Date: | August 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8311 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6679 |
|
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT(STUN) extension used in the optional initialisation method usingInteractive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. |
|
| |
| RFC 6680 | Generic Security Service Application Programming Interface (GSS-API) Naming Extensions |
| |
| Authors: | N. Williams, L. Johansson, S. Hartman, S. Josefsson. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6680 |
|
The Generic Security Service Application Programming Interface(GSS-API) provides a simple naming architecture that supports name- based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer betweenGSS-API peers. |
|
| |
| RFC 6681 | Raptor Forward Error Correction (FEC) Schemes for FECFRAME |
| |
| Authors: | M. Watson, T. Stockhammer, M. Luby. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6681 |
|
This document describes Fully-Specified Forward Error Correction(FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FECFramework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. TheRaptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FECSchemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport(e.g., UDP) or using RTP. |
|
| |
| RFC 6682 | RTP Payload Format for Raptor Forward Error Correction (FEC) |
| |
| Authors: | M. Watson, T. Stockhammer, M. Luby. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6682 |
|
This document specifies an RTP payload format for the Forward ErrorCorrection (FEC) repair data produced by the Raptor FEC Schemes.Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP.This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. |
|
| |
| RFC 6683 | Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection |
| |
| Authors: | A. Begen, T. Stockhammer. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6683 |
|
Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward ErrorCorrection (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. |
|
| |
| RFC 6684 | Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) |
| |
| Authors: | B. Trammell. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6684 |
|
This document provides guidelines for extensions to the IncidentObject Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template forInternet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. |
|
| |
| RFC 6685 | Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry |
| |
|
|
This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require ExpertReview for extensions to Incident Object Description Exchange Format(IODEF). |
|
| |
| RFC 6686 | Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |
| |
| Authors: | M. Kucherawy. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6686 |
|
In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
The IESG required all of these documents (RFC 4405, RFC 4406, RFC4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.
After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. |
|
| |
| RFC 6687 | Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed.. |
| Date: | October 2012 |
| Formats: | txt json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6687 |
|
This document presents a performance evaluation of the RoutingProtocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network.Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios.Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. |
|
| |
| RFC 6688 | Parallel NFS (pNFS) Block Disk Protection |
| |
| Authors: | D. Black, Ed., J. Glasgow, S. Faibish. |
| Date: | July 2012 |
| Formats: | txt html json |
| Updates: | RFC 5663 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6688 |
|
Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. |
|
| |
| RFC 6689 | Usage of the RSVP ASSOCIATION Object |
| |
| Authors: | L. Berger. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6689 |
|
The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths(LSPs). In this context, the object is used to associate recoveryLSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. |
|
| |
| RFC 6690 | Constrained RESTful Environments (CoRE) Link Format |
| |
| Authors: | Z. Shelby. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6690 |
|
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTPLink Header field defined in RFC 5988, the Constrained RESTfulEnvironments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to theRepresentational State Transfer (REST) architecture. A well-knownURI is defined as a default entry point for requesting the links hosted by a server. |
|
| |
| RFC 6691 | TCP Options and Maximum Segment Size (MSS) |
| |
|
|
This memo discusses what value to use with the TCP Maximum SegmentSize (MSS) option, and updates RFC 879 and RFC 2385. |
|
| |
| RFC 6692 | Source Ports in Abuse Reporting Format (ARF) Reports |
| |
|
|
This document defines an additional header field for use in AbuseReporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.
This document updates RFC 6591. |
|
| |
| RFC 6693 | Probabilistic Routing Protocol for Intermittently Connected Networks |
| |
| Authors: | A. Lindgren, A. Doria, E. Davies, S. Grasic. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6693 |
|
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.
This document defines PRoPHET, a Probabilistic Routing Protocol usingHistory of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. |
|
| |
| RFC 6694 | The "about" URI Scheme |
| |
| Authors: | S. Moonesamy, Ed.. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6694 |
|
This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. |
|
| |
| RFC 6695 | Methods to Convey Forward Error Correction (FEC) Framework Configuration Information |
| |
| Authors: | R. Asati. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6695 |
|
The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for theFEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time StreamingProtocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
This document doesn't define any new signaling protocol. |
|
| |
| RFC 6696 | EAP Extensions for the EAP Re-authentication Protocol (ERP) |
| |
| Authors: | Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed.. |
| Date: | July 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 5296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6696 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
This memo obsoletes RFC 5296. |
|
| |
| RFC 6697 | Handover Keying (HOKEY) Architecture Design |
| |
| Authors: | G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6697 |
|
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY WorkingGroup. |
|
| |
| RFC 6698 | The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA |
| |
|
|
Encrypted communication on the Internet often uses Transport LayerSecurity (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. |
|
