| |
| RFC 6701 | Sanctions Available for Application to Violators of IETF IPR Policy |
| |
| Authors: | A. Farrel, P. Resnick. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6701 |
|
The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to IntellectualProperty Rights (IPR) about which they might reasonably be aware.
The IETF takes conformance to these IPR policies very seriously.However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.
This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. |
|
| |
| RFC 6702 | Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules |
| |
|
|
The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. |
|
| |
| RFC 6703 | Reporting IP Network Performance Metrics: Different Points of View |
| |
| Authors: | A. Morton, G. Ramachandran, G. Maguluri. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6703 |
|
Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations(e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. |
|
| |
| RFC 6704 | Forcerenew Nonce Authentication |
| |
| Authors: | D. Miles, W. Dec, J. Bristow, R. Maglione. |
| Date: | August 2012 |
| Formats: | txt html json |
| Updates: | RFC 3203 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6704 |
|
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into aRenew state on a trigger from the DHCP server. In the ForcerenewNonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of aFORCERENEW message. This document updates RFC 3203. |
|
| |
| RFC 6705 | Localized Routing for Proxy Mobile IPv6 |
| |
| Authors: | S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6705 |
|
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) andLocal Routing Acknowledgment (LRA), that are used to realize this mechanism. |
|
| |
| RFC 6706 | Asymmetric Extended Route Optimization (AERO) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6706 |
|
Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.This document therefore introduces an Asymmetric Extended RouteOptimization (AERO) capability that addresses the issues. |
|
| |
| RFC 6707 | Content Distribution Network Interconnection (CDNI) Problem Statement |
| |
| Authors: | B. Niven-Jenkins, F. Le Faucheur, N. Bitar. |
| Date: | September 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6707 |
|
Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that EndUser's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.
The goal of this document is to outline the problem area of CDNInterconnection for the IETF CDNI (CDN Interconnection) working group. |
|
| |
| RFC 6708 | Application-Layer Traffic Optimization (ALTO) Requirements |
| |
| Authors: | S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6708 |
|
Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance orQuality of Experience in the application while reducing the utilization of the underlying network infrastructure.
This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. |
|
| |
| RFC 6709 | Design Considerations for Protocol Extensions |
| |
| Authors: | B. Carpenter, B. Aboba, Ed., S. Cheshire. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6709 |
|
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. |
|
| |
| RFC 6710 | Simple Mail Transfer Protocol Extension for Message Transfer Priorities |
| |
| Authors: | A. Melnikov, K. Carlberg. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6710 |
|
This memo defines an extension to the SMTP (Simple Mail TransferProtocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. |
|
| |
| RFC 6711 | An IANA Registry for Level of Assurance (LoA) Profiles |
| |
| Authors: | L. Johansson. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6711 |
|
This document establishes an IANA registry for Level of Assurance(LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 andOpenID Connect. |
|
| |
| RFC 6712 | Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) |
| |
|
|
This document describes how to layer the Certificate ManagementProtocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. |
|
| |
| RFC 6713 | The 'application/zlib' and 'application/gzip' Media Types |
| |
| Authors: | J. Levine. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6713 |
|
This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. |
|
| |
| RFC 6714 | Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | C. Holmberg, S. Blau, E. Burger. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6714 |
|
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA).Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol(SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. |
|
| |
| RFC 6715 | vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group |
| |
| Authors: | D. Cauchie, B. Leiba, K. Li. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6715 |
|
This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance(OMA) Converged Address Book group, in order to synchronize, usingOMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. |
|
| |
| RFC 6716 | Definition of the Opus Audio Codec |
| |
| Authors: | JM. Valin, K. Vos, T. Terriberry. |
| Date: | September 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8251 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6716 |
|
This document defines the Opus interactive speech and audio codec.Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and theModified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. |
|
| |
| RFC 6717 | kx509 Kerberized Certificate Issuance Protocol in Use in 2012 |
| |
| Authors: | H. Hotz, R. Allbery. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6717 |
|
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. |
|
| |
| RFC 6718 | Pseudowire Redundancy |
| |
| Authors: | P. Muley, M. Aissaoui, M. Bocci. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6718 |
|
This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy.A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. |
|
| |
| RFC 6719 | The Minimum Rank with Hysteresis Objective Function |
| |
| Authors: | O. Gnawali, P. Levis. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6719 |
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function(MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPLDestination Information Object (DIO) messages advertise. |
|
| |
| RFC 6720 | The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) |
| |
|
|
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for theLabel Distribution Protocol (LDP).
This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. |
|
| |
| RFC 6721 | The Atom "deleted-entry" Element |
| |
| Authors: | J. Snell. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6721 |
|
This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. |
|
| |
| RFC 6722 | Publishing the "Tao of the IETF" as a Web Page |
| |
|
|
This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. |
|
| |
| RFC 6723 | Update of the Pseudowire Control-Word Negotiation Mechanism |
| |
|
|
The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. |
|
| |
| RFC 6724 | Default Address Selection for Internet Protocol Version 6 (IPv6) |
| |
| Authors: | D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. |
| Date: | September 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3484 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6724 |
|
This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.
Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. |
|
| |
| RFC 6725 | DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates |
| |
| Authors: | S. Rose. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6725 |
|
The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.The algorithms specified for use with DNSSEC are reflected in anIANA-maintained registry. This document presents a set of changes for some entries of the registry. |
|
| |
| RFC 6726 | FLUTE - File Delivery over Unidirectional Transport |
| |
| Authors: | T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen. |
| Date: | November 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 3926 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6726 |
|
This document defines File Delivery over Unidirectional Transport(FLUTE), a protocol for the unidirectional delivery of files over theInternet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.This document obsoletes RFC 3926. |
|
| |
| RFC 6727 | Definitions of Managed Objects for Packet Sampling |
| |
| Authors: | T. Dietz, Ed., B. Claise, J. Quittek. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6727 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes extensions to the IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP-MIB module containing managed objects for providing information on applied packet selection functions and their parameters. |
|
| |
| RFC 6728 | Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols |
| |
| Authors: | G. Muenz, B. Claise, P. Aitken. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6728 |
|
This document specifies a data model for the IP Flow InformationExport (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, ExportingProcesses, and Collecting Processes of IPFIX- and PSAMP-compliantMonitoring Devices using the Network Configuration Protocol(NETCONF). The data model is defined using UML (Unified ModelingLanguage) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). |
|
| |
| RFC 6729 | Indicating Email Handling States in Trace Fields |
| |
| Authors: | D. Crocker, M. Kucherawy. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6729 |
|
This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. |
|
| |
| RFC 6730 | Requirements for IETF Nominations Committee Tools |
| |
| Authors: | S. Krishnan, J. Halpern. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6730 |
|
This document defines the requirements for a set of tools for use by the IETF Nominations Committee. |
|
| |
| RFC 6731 | Improved Recursive DNS Server Selection for Multi-Interfaced Nodes |
| |
| Authors: | T. Savolainen, J. Kato, T. Lemon. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6731 |
|
A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describesDHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. |
|
| |
| RFC 6732 | 6to4 Provider Managed Tunnels |
| |
| Authors: | V. Kuarsingh, Ed., Y. Lee, O. Vautrin. |
| Date: | September 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7526 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6732 |
|
6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. |
|
| |
| RFC 6733 | Diameter Base Protocol |
| |
|
|
The Diameter base protocol is intended to provide an Authentication,Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by allDiameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. |
|
| |
| RFC 6734 | Diameter Attribute-Value Pairs for Cryptographic Key Transport |
| |
| Authors: | G. Zorn, Q. Wu, V. Cakulev. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6734 |
|
Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. |
|
| |
| RFC 6735 | Diameter Priority Attribute-Value Pairs |
| |
| Authors: | K. Carlberg, Ed., T. Taylor. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6735 |
|
This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and theAuthentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. |
|
| |
| RFC 6736 | Diameter Network Address and Port Translation Control Application |
| |
| Authors: | F. Brockners, S. Bhandari, V. Singh, V. Fajardo. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6736 |
|
This document describes the framework, messages, and procedures for the Diameter Network address and port translation ControlApplication. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and PortTranslators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a NetworkAddress Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator andNetwork Address and Port Translator device. This includes, for example, the control of the total number of Network AddressTranslator bindings allowed or the allocation of a specific NetworkAddress Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. |
|
| |
| RFC 6737 | The Diameter Capabilities Update Application |
| |
| Authors: | K. Jiao, G. Zorn. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6737 |
|
This document defines a new Diameter application and associatedCommand Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. |
|
| |
| RFC 6738 | Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers |
| |
| Authors: | V. Cakulev, A. Lior, S. Mizikovsky. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6738 |
|
The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec SecurityAssociations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the ExtensibleAuthentication Protocol (EAP), certificates, and Shared Key (SK).
Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified.However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2.This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. |
|
| |
| RFC 6739 | Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol |
| |
| Authors: | H. Schulzrinne, H. Tschofenig. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6739 |
|
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriatePublic Safety Answering Point (PSAP) for emergency services.
The <mapping&rt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform ResourceIdentifier (URI) or set of URIs for a given service.
This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping&rt; elements between two entities. Exchanging cached <mapping&rt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping&rt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. |
|
| |
| RFC 6740 | Identifier-Locator Network Protocol (ILNP) Architectural Description |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6740 |
|
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6741 | Identifier-Locator Network Protocol (ILNP) Engineering Considerations |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6741 |
|
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol(ILNP), which is an experimental, evolutionary enhancement to IP.This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6742 | DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti, S. Rose. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6742 |
|
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6743 | ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6743 |
|
This note specifies an experimental ICMPv6 message type used with theIdentifier-Locator Network Protocol (ILNP). The Identifier-LocatorNetwork Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group. |
|
| |
| RFC 6744 | IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6744 |
|
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations.This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of theIRTF Routing Research Group. |
|
| |
| RFC 6745 | ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6745 |
|
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group. |
|
| |
| RFC 6746 | IPv4 Options for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6746 |
|
This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6747 | Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6747 |
|
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6748 | Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6748 |
|
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for theIdentifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management ofILNP-based systems. |
|
| |
| RFC 6749 | The OAuth 2.0 Authorization Framework |
| |
|
|
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. |
|
| |
| RFC 6750 | The OAuth 2.0 Authorization Framework: Bearer Token Usage |
| |
|
|
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. |
|
| |
| RFC 6751 | Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) |
| |
| Authors: | R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6751 |
|
In customer sites having IPv4-only Customer Premises Equipment (CPE),Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs(an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. |
|
| |
| RFC 6752 | Issues with Private IP Addressing in the Internet |
| |
| Authors: | A. Kirkham. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6752 |
|
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. |
|
| |
| RFC 6753 | A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) |
| |
| Authors: | J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6753 |
|
This document describes how to use the Hypertext Transfer Protocol(HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format LocationObject (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-EnabledLocation Delivery (HELD) protocol to request the location of theTarget. |
|
| |
| RFC 6754 | Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect |
| |
|
|
A Protocol Independent Multicast (PIM) router uses the Reverse PathForwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources.This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. |
|
| |
| RFC 6755 | An IETF URN Sub-Namespace for OAuth |
| |
| Authors: | B. Campbell, H. Tschofenig. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6755 |
|
This document establishes an IETF URN Sub-namespace for use withOAuth-related specifications. |
|
| |
| RFC 6756 | Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines |
| |
| Authors: | S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. |
| Date: | September 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3356 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6756 |
|
This document provides guidance to aid in the understanding of collaboration on standards development between the TelecommunicationStandardization Sector of the International Telecommunication Union(ITU-T) and the Internet Engineering Task Force (IETF) of theInternet Society (ISOC). It is an update of and obsoletes RFC 3356.The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T ASeries Supplement 3 (07/2012).
Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to theITU-T A-Series of Recommendations. |
|
| |
| RFC 6757 | Access Network Identifier (ANI) Option for Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 7563 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6757 |
|
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. |
|
| |
| RFC 6758 | Tunneling of SMTP Message Transfer Priorities |
| |
| Authors: | A. Melnikov, K. Carlberg. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6758 |
|
This memo defines a mechanism for tunneling of SMTP (Simple MailTransfer Protocol) Message Transfer Priority values through MTAs(Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. |
|
| |
| RFC 6759 | Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Claise, P. Aitken, N. Ben-Dvora. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6759 |
|
This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. |
|
| |
| RFC 6760 | Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6760 |
|
One of the goals of the authors of Multicast DNS (mDNS) and DNS-BasedService Discovery (DNS-SD) was to retire AppleTalk and the AppleTalkName Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement. |
|
| |
| RFC 6761 | Special-Use Domain Names |
| |
|
|
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. |
|
| |
| RFC 6762 | Multicast DNS |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6762 |
|
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventionalUnicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. |
|
| |
| RFC 6763 | DNS-Based Service Discovery |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6763 |
|
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standardDNS queries. This mechanism is referred to as DNS-based ServiceDiscovery, or DNS-SD. |
|
| |
| RFC 6764 | Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) |
| |
|
|
This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locateCalDAV (Calendaring Extensions to Web Distributed Authoring andVersioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services. |
|
| |
| RFC 6765 | xDSL Multi-Pair Bonding (G.Bond) MIB |
| |
| Authors: | E. Beili, M. Morgenstern. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6765 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-TRecommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separateMIB module maintained by Internet Assigned Numbers Authority (IANA).The MIB modules specific to each bonding technology are defined inG9981-MIB, G9982-MIB, and G9983-MIB, respectively. |
|
| |
| RFC 6766 | xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB |
| |
| Authors: | E. Beili. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6766 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces usingTime-Division Inverse Multiplexing (TDIM), as defined in ITU-TRecommendation G.998.3. |
|
| |
| RFC 6767 | Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB |
| |
| Authors: | E. Beili, M. Morgenstern. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6767 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-T RecommendationG.998.2. |
|
| |
| RFC 6768 | ATM-Based xDSL Bonded Interfaces MIB |
| |
| Authors: | E. Beili. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6768 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1. |
|
| |
| RFC 6769 | Simple Virtual Aggregation (S-VA) |
| |
| Authors: | R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6769 |
|
All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into theForwarding Information Base (FIB).
Some routers in an Autonomous System (AS) announce an aggregate (theVA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.
The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. |
|
| |
| RFC 6770 | Use Cases for Content Delivery Network Interconnection |
| |
| Authors: | G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 3570 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6770 |
|
Content Delivery Networks (CDNs) are commonly used for improving theEnd User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC3570. |
|
| |
| RFC 6771 | Considerations for Having a Successful "Bar BOF" Side Meeting |
| |
| Authors: | L. Eggert, G. Camarillo. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6771 |
|
New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "barBOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.
During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.
This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. |
|
| |
| RFC 6772 | Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information |
| |
| Authors: | H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6772 |
|
This document defines an authorization policy language for controlling access to location information. It extends the CommonPolicy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. |
|
| |
| RFC 6773 | DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal |
| |
|
|
This document specifies an alternative encapsulation of the DatagramCongestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates theSession Description Protocol (SDP) information for DCCP defined inRFC 5762. |
|
| |
| RFC 6774 | Distribution of Diverse BGP Paths |
| |
| Authors: | R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6774 |
|
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, theNth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.
This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge(PE) routers acting as route reflector clients. |
|
| |
| RFC 6775 | Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
|
|
The IETF work in IPv6 over Low-power Wireless Personal Area Network(6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. |
|
| |
| RFC 6776 | Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block |
| |
| Authors: | A. Clark, Q. Wu. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6776 |
|
This document defines an RTP Control Protocol (RTCP) SourceDescription (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. |
|
| |
| RFC 6777 | Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks |
| |
| Authors: | W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6777 |
|
When setting up a Label Switched Path (LSP) in Generalized MPLS(GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and useLSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. |
|
| |
| RFC 6778 | Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching |
| |
| Authors: | R. Sparks. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6778 |
|
The IETF makes heavy use of email lists to conduct its work.Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. |
|
| |
| RFC 6779 | Definition of Managed Objects for the Neighborhood Discovery Protocol |
| |
| Authors: | U. Herberg, R. Cole, I. Chakeres. |
| Date: | October 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7939 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6779 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. |
|
| |
| RFC 6780 | RSVP ASSOCIATION Object Extensions |
| |
|
|
The RSVP ASSOCIATION object was defined in the context of GMPLS- controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting.This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also definesExtended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. |
|
| |
| RFC 6781 | DNSSEC Operational Practices, Version 2 |
| |
| Authors: | O. Kolkman, W. Mekking, R. Gieben. |
| Date: | December 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 4641 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6781 |
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. |
|
| |
| RFC 6782 | Wireline Incremental IPv6 |
| |
| Authors: | V. Kuarsingh, Ed., L. Howard. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6782 |
|
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. |
|
| |
| RFC 6783 | Mailing Lists and Non-ASCII Addresses |
| |
|
|
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. |
|
| |
| RFC 6784 | Kerberos Options for DHCPv6 |
| |
| Authors: | S. Sakane, M. Ishiyama. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6784 |
|
This document defines four new options for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. |
|
| |
| RFC 6785 | Support for Internet Message Access Protocol (IMAP) Events in Sieve |
| |
|
|
Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. |
|
| |
| RFC 6786 | Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs |
| |
| Authors: | A. Yegin, R. Cragie. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6786 |
|
This document specifies a mechanism for delivering the Protocol forCarrying Authentication for Network Access (PANA) Attribute-ValuePairs (AVPs) in encrypted form. |
|
| |
| RFC 6787 | Media Resource Control Protocol Version 2 (MRCPv2) |
| |
| Authors: | D. Burnett, S. Shanmugham. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6787 |
|
The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, theMRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. |
|
| |
| RFC 6788 | The Line-Identification Option |
| |
| Authors: | S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6788 |
|
In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received RouterSolicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. |
|
| |
| RFC 6789 | Congestion Exposure (ConEx) Concepts and Use Cases |
| |
| Authors: | B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed.. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6789 |
|
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. |
|
| |
| RFC 6790 | The Use of Entropy Labels in MPLS Forwarding |
| |
|
|
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing acrossMPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. |
|
| |
| RFC 6791 | Stateless Source Address Mapping for ICMPv6 Packets |
| |
| Authors: | X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. |
| Date: | November 2012 |
| Formats: | txt json html |
| Updates: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6791 |
|
A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. |
|
| |
| RFC 6792 | Guidelines for Use of the RTP Monitoring Framework |
| |
| Authors: | Q. Wu, Ed., G. Hunt, P. Arden. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6792 |
|
This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. |
|
| |
| RFC 6793 | BGP Support for Four-Octet Autonomous System (AS) Number Space |
| |
|
|
The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. |
|
| |
| RFC 6794 | A Framework for Session Initiation Protocol (SIP) Session Policies |
| |
| Authors: | V. Hilt, G. Camarillo, J. Rosenberg. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6794 |
|
Proxy servers play a central role as an intermediary in the SessionInitiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. |
|
| |
| RFC 6795 | A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies |
| |
| Authors: | V. Hilt, G. Camarillo. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6795 |
|
This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. |
|
| |
| RFC 6796 | A User Agent Profile Data Set for Media Policy |
| |
| Authors: | V. Hilt, G. Camarillo, J. Rosenberg, D. Worley. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6796 |
|
This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions.Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. |
|
| |
| RFC 6797 | HTTP Strict Transport Security (HSTS) |
| |
| Authors: | J. Hodges, C. Jackson, A. Barth. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6797 |
|
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to asHTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. |
|
| |
| RFC 6798 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting |
| |
| Authors: | A. Clark, Q. Wu. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6798 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. |
|
