| |
| RFC 6501 | Conference Information Data Model for Centralized Conferencing (XCON) |
| |
| Authors: | O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6501 |
|
RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in theSession Initiation Protocol (SIP) event package for conference State. |
|
| |
| RFC 6502 | Conference Event Package Data Format Extension for Centralized Conferencing (XCON) |
| |
| Authors: | G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6502 |
|
This document specifies the notification mechanism for XCON(centralized conferencing). This mechanism reuses the SIP (SessionInitiation Protocol) event package for conference state.Additionally, the notification mechanism includes support for theXCON data model and for partial notifications. |
|
| |
| RFC 6503 | Centralized Conferencing Manipulation Protocol |
| |
| Authors: | M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6503 |
|
The Centralized Conferencing Manipulation Protocol (CCMP) allows aCentralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference.CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. |
|
| |
| RFC 6504 | Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples |
| |
| Authors: | M. Barnes, L. Miniero, R. Presta, S P. Romano. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6504 |
|
This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized ConferencingManipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. |
|
| |
| RFC 6505 | A Mixer Control Package for the Media Control Channel Framework |
| |
| Authors: | S. McGlashan, T. Melanchuk, C. Boulton. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6505 |
|
This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. |
|
| |
| RFC 6506 | Supporting Authentication Trailer for OSPFv3 |
| |
| Authors: | M. Bhatia, V. Manral, A. Lindem. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6506 |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. |
|
| |
| RFC 6507 | Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6507 |
|
Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve- based Certificateless Signatures for Identity-based Encryption(ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. |
|
| |
| RFC 6508 | Sakai-Kasahara Key Encryption (SAKKE) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6508 |
|
In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. |
|
| |
| RFC 6509 | MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6509 |
|
This document describes the Multimedia Internet KEYing-Sakai-KasaharaKey Encryption (MIKEY-SAKKE), a method of key exchange that usesIdentity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. |
|
| |
| RFC 6510 | Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions may be signaled with a set of LSP- specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. |
|
| |
| RFC 6511 | Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths |
| |
| Authors: | Z. Ali, G. Swallow, R. Aggarwal. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6511 |
|
There are many deployment scenarios that require an egress LabelSwitching Router (LSR) to receive binding of the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band"(OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. |
|
| |
| RFC 6512 | Using Multipoint LDP When the Backbone Has No Route to the Root |
| |
| Authors: | IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6512 |
|
The control protocol used for constructing Point-to-Multipoint andMultipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of aBGP-free core. This document specifies procedures that enable an MPLSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. |
|
| |
| RFC 6513 | Multicast in MPLS/BGP IP VPNs |
| |
|
|
In order for IP multicast traffic within a BGP/MPLS IP VPN (VirtualPrivate Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN ServiceProvider. These protocols and procedures are specified in this document. |
|
| |
| RFC 6514 | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
| Authors: | R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 6515, RFC 6625, RFC 7385, RFC 7441, RFC 7582, RFC 7899, RFC 7900, RFC 7902, RFC 7988, RFC 8534, RFC 9081 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6514 |
|
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGPIP VPNs, as specified in RFC 6513. |
|
| |
| RFC 6515 | IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN |
| |
| Authors: | R. Aggarwal, E. Rosen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6515 |
|
To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN")BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses.To ensure interoperability, this document specifies that providerIPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. |
|
| |
| RFC 6516 | IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages |
| |
| Authors: | Y. Cai, E. Rosen, Ed., I. Wijnands. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6516 |
|
The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider MulticastService Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. |
|
| |
| RFC 6517 | Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution |
| |
| Authors: | T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6517 |
|
More that one set of mechanisms to support multicast in a layer 3BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.
To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. |
|
| |
| RFC 6518 | Keying and Authentication for Routing Protocols (KARP) Design Guidelines |
| |
| Authors: | G. Lebovitz, M. Bhatia. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6518 |
|
This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. |
|
| |
| RFC 6519 | RADIUS Extensions for Dual-Stack Lite |
| |
| Authors: | R. Maglione, A. Durand. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6519 |
|
Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-StackLite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication,Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic HostConfiguration Protocol (DHCP). This document specifies a new RemoteAuthentication Dial-In User Service (RADIUS) attribute to carry theDual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and theNetwork Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. |
|
| |
| RFC 6520 | Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension |
| |
| Authors: | R. Seggelmann, M. Tuexen, M. Williams. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6520 |
|
This document describes the Heartbeat Extension for the TransportLayer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. |
|
| |
| RFC 6521 | Home Agent-Assisted Route Optimization between Mobile IPv4 Networks |
| |
| Authors: | A. Makela, J. Korhonen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6521 |
|
This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. |
|
| |
| RFC 6522 | The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
This memo obsoletes "The Multipart/Report Content Type for theReporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". |
|
| |
| RFC 6525 | Stream Control Transmission Protocol (SCTP) Stream Reconfiguration |
| |
| Authors: | R. Stewart, M. Tuexen, P. Lei. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6525 |
|
Many applications that use the Stream Control Transmission Protocol(SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. |
|
| |
| RFC 6526 | IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream |
| |
| Authors: | B. Claise, P. Aitken, A. Johnson, G. Muenz. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6526 |
|
This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the PartialReliability extension of SCTP (PR-SCTP, Partial Reliability StreamControl Transmission Protocol).
When implemented at both the Exporting Process and CollectingProcess, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of TemplateIDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. |
|
| |
| RFC 6527 | Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) |
| |
|
|
This specification defines a portion of the Management InformationBase (MIB) for use with network management based on the SimpleNetwork Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC2787. |
|
| |
| RFC 6528 | Defending against Sequence Number Attacks |
| |
|
|
This document specifies an algorithm for the generation of TCPInitial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. |
|
| |
| RFC 6529 | Host/Host Protocol for the ARPA Network |
| |
| Authors: | A. McKenzie, S. Crocker. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6529 |
|
This document reproduces the Host/Host Protocol developed by the ARPANetwork Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of theARPA Network from January 1972 until the switch to TCP/IP in January1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. |
|
| |
| RFC 6530 | Overview and Framework for Internationalized Email |
| |
|
|
Full use of electronic mail throughout the world requires that(subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC4952; it reflects additional issues identified since that document was published. |
|
| |
| RFC 6531 | SMTP Extension for Internationalized Email |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. |
|
| |
| RFC 6532 | Internationalized Email Headers |
| |
|
|
Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.
This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". |
|
| |
| RFC 6533 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. |
|
| |
| RFC 6534 | Loss Episode Metrics for IP Performance Metrics (IPPM) |
| |
| Authors: | N. Duffield, A. Morton, J. Sommers. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6534 |
|
The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts.However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. |
|
| |
| RFC 6535 | Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) |
| |
|
|
Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 andRFC 3338. |
|
| |
| RFC 6536 | Network Configuration Protocol (NETCONF) Access Control Model |
| |
| Authors: | A. Bierman, M. Bjorklund. |
| Date: | March 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8341 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6536 |
|
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. |
|
| |
| RFC 6537 | Host Identity Protocol Distributed Hash Table Interface |
| |
| Authors: | J. Ahrenholz. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6537 |
|
This document specifies a common interface for using the HostIdentity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service. |
|
| |
| RFC 6538 | The Host Identity Protocol (HIP) Experiment Report |
| |
| Authors: | T. Henderson, A. Gurtov. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6538 |
|
This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. |
|
| |
| RFC 6539 | IBAKE: Identity-Based Authenticated Key Exchange |
| |
| Authors: | V. Cakulev, G. Sundaram, I. Broustis. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6539 |
|
Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure(PKI) to support certificate management. The emerging field ofIdentity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange(IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. |
|
| |
| RFC 6540 | IPv6 Support Required for All IP-Capable Nodes |
| |
| Authors: | W. George, C. Donley, C. Liljenstolpe, L. Howard. |
| Date: | April 2012 |
| Formats: | txt json html |
| Also: | BCP 0177 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6540 |
|
Given the global lack of available IPv4 space, and limitations inIPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, orIPv4-only, depending on context and application. |
|
| |
| RFC 6541 | DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures |
| |
| Authors: | M. Kucherawy. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6541 |
|
This experimental specification proposes a modification to DomainKeysIdentified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. |
|
| |
| RFC 6542 | Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility |
| |
|
|
Currently, channel bindings are implemented using an MD5 hash in theKerberos Version 5 Generic Security Service Application ProgrammingInterface (GSS-API) mechanism (RFC 4121). This document updates RFC4121 to allow channel bindings using algorithms negotiated based onKerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in theKerberos client-server exchange message, extensions are defined to allow future protocol extensions. |
|
| |
| RFC 6543 | Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 |
| |
|
|
Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose.This document also updates RFC 5213. |
|
| |
| RFC 6544 | TCP Candidates with Interactive Connectivity Establishment (ICE) |
| |
| Authors: | J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6544 |
|
Interactive Connectivity Establishment (ICE) defines a mechanism forNAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on SessionTraversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams.This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. |
|
| |
| RFC 6545 | Real-time Inter-network Defense (RID) |
| |
|
|
Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. |
|
| |
| RFC 6546 | Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. |
|
| |
| RFC 6547 | RFC 3627 to Historic Status |
| |
|
|
This document moves "Use of /127 Prefix Length Between RoutersConsidered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter-Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. |
|
| |
| RFC 6548 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrativeOversight Committee (IAOC). |
|
| |
| RFC 6549 | OSPFv2 Multi-Instance Extensions |
| |
| Authors: | A. Lindem, A. Roy, S. Mirtorabi. |
| Date: | March 2012 |
| Formats: | txt json html |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6549 |
|
OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.
This document defines the OSPFv2 Instance ID to enable separateOSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.
This document updates RFC 2328. |
|
| |
| RFC 6550 | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks |
| |
| Authors: | T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. |
| Date: | March 2012 |
| Formats: | txt json html |
| Updated by: | RFC 9008, RFC 9010 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6550 |
|
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside theLLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks(RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. |
|
| |
| RFC 6551 | Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks |
| |
| Authors: | JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6551 |
|
Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). |
|
| |
| RFC 6552 | Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | P. Thubert, Ed.. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6552 |
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specificObjective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPLInstance based on the Information Objects available; an OF is not an algorithm.
This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. |
|
| |
| RFC 6553 | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams |
| |
|
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes theRPL Option for use among RPL routers to include such routing information. |
|
| |
| RFC 6554 | An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | J. Hui, JP. Vasseur, D. Culler, V. Manral. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6554 |
|
In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The RoutingProtocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., theDirected Acyclic Graph (DAG) root) or a few routers and forward theIPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a newIPv6 Routing header type for delivering datagrams within a RPL routing domain. |
|
| |
| RFC 6555 | Happy Eyeballs: Success with Dual-Stack Hosts |
| |
| Authors: | D. Wing, A. Yourtchenko. |
| Date: | April 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8305 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6555 |
|
When a server's IPv4 path and protocol are working, but the server'sIPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to anIPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. |
|
| |
| RFC 6556 | Testing Eyeball Happiness |
| |
| Authors: | F. Baker. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6556 |
|
The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering.This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. |
|
| |
| RFC 6557 | Procedures for Maintaining the Time Zone Database |
| |
|
|
Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone(TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. |
|
| |
| RFC 6558 | Sieve Extension for Converting Messages before Delivery |
| |
| Authors: | A. Melnikov, B. Leiba, K. Li. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6558 |
|
This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. |
|
| |
| RFC 6559 | A Reliable Transport Mechanism for PIM |
| |
| Authors: | D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6559 |
|
This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing.The reliable transport mechanism can use either TCP or SCTP as the transport protocol. |
|
| |
| RFC 6560 | One-Time Password (OTP) Pre-Authentication |
| |
| Authors: | G. Richards. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6560 |
|
The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password(OTP) authentication. |
|
| |
| RFC 6561 | Recommendations for the Remediation of Bots in ISP Networks |
| |
| Authors: | J. Livingood, N. Mody, M. O'Reirdan. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6561 |
|
This document contains recommendations on how Internet ServiceProviders can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular InternetService Provider's network. |
|
| |
| RFC 6562 | Guidelines for the Use of Variable Bit Rate Audio with Secure RTP |
| |
| Authors: | C. Perkins, JM. Valin. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6562 |
|
This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.Guidelines to mitigate these issues are suggested. |
|
| |
| RFC 6563 | Moving A6 to Historic Status |
| |
| Authors: | S. Jiang, D. Conrad, B. Carpenter. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6563 |
|
This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. |
|
| |
| RFC 6564 | A Uniform Format for IPv6 Extension Headers |
| |
| Authors: | S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6564 |
|
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport- layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. |
|
| |
| RFC 6565 | OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol |
| |
| Authors: | P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6565 |
|
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge(CE) routers are routing peers of Provider Edge (PE) routers. TheBorder Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and MultiprotocolLabel Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6VPNs; however, only Open Shortest Path First version 2 (OSPFv2) asPE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that ofOSPFv2 except for the differences described in this document. |
|
| |
| RFC 6566 | A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6566 |
|
As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.
This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to supportImpairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation.This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. |
|
| |
| RFC 6567 | Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP |
| |
| Authors: | A. Johnston, L. Liess. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6567 |
|
This document introduces the transport of call control User-to-UserInformation (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application.This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network(ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. |
|
| |
| RFC 6568 | Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | E. Kim, D. Kaspar, JP. Vasseur. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6568 |
|
This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications.A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. |
|
| |
| RFC 6569 | Guidelines for Development of an Audio Codec within the IETF |
| |
| Authors: | JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6569 |
|
This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. |
|
| |
| RFC 6570 | URI Template |
| |
| Authors: | J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6570 |
|
A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. |
|
| |
| RFC 6571 | Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks |
| |
| Authors: | C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6571 |
|
In this document, we analyze the applicability of the Loop-FreeAlternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. |
|
| |
| RFC 6572 | RADIUS Support for Proxy Mobile IPv6 |
| |
| Authors: | F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. |
| Date: | June 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8044 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6572 |
|
This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-basedAAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. |
|
| |
| RFC 6573 | The Item and Collection Link Relations |
| |
| Authors: | M. Amundsen. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6573 |
|
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. |
|
| |
| RFC 6574 | Report from the Smart Object Workshop |
| |
| Authors: | H. Tschofenig, J. Arkko. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6574 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on 'Interconnecting Smart Objects with theInternet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet EngineeringTask Force (IETF) community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 6575 | Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs |
| |
| Authors: | H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6575 |
|
The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge(CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the AttachmentCircuits must be of the same technology (e.g., both Ethernet or bothATM), and the pseudowire must carry the frames of that technology.However, if it is known that the frames' payload consists solely ofIP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as"Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. |
|
| |
| RFC 6576 | IP Performance Metrics (IPPM) Standard Advancement Testing |
| |
| Authors: | R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. |
| Date: | March 2012 |
| Formats: | txt html json |
| Also: | BCP 0176 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6576 |
|
This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along theStandards Track. Results from different implementations of metricRFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is anInternet Best Current Practice. |
|
| |
| RFC 6577 | Authentication-Results Registration Update for Sender Policy Framework (SPF) Results |
| |
|
|
This memo updates the registry of authentication method results inAuthentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SenderPolicy Framework (SPF) specification.
This memo updates RFC 5451. |
|
| |
| RFC 6578 | Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) |
| |
| Authors: | C. Daboo, A. Quillaud. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6578 |
|
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. |
|
| |
| RFC 6579 | The 'disclosure' Link Relation Type |
| |
| Authors: | M. Yevstifeyev. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6579 |
|
This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. |
|
| |
| RFC 6580 | IANA Registries for the Remote Direct Data Placement (RDDP) Protocols |
| |
| Authors: | M. Ko, D. Black. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6580 |
|
The original RFCs that specified the Remote Direct Data Placement(RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. |
|
| |
| RFC 6581 | Enhanced Remote Direct Memory Access (RDMA) Connection Establishment |
| |
|
|
This document updates RFC 5043 and RFC 5044 by extending MarkerProtocol Data Unit (PDU) Aligned Framing (MPA) negotiation for RemoteDirect Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. |
|
| |
| RFC 6582 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
| Authors: | T. Henderson, S. Floyd, A. Gurtov, Y. Nishida. |
| Date: | April 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3782 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6582 |
|
RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as"NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. |
|
| |
| RFC 6583 | Operational Neighbor Discovery Problems |
| |
| Authors: | I. Gashinsky, J. Jaeggli, W. Kumari. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6583 |
|
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of NeighborDiscovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. |
|
| |
| RFC 6584 | Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6584 |
|
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) protocols. The first scheme is based on RSA DigitalSignatures. The second scheme relies on the Elliptic Curve DigitalSignature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. |
|
| |
| RFC 6585 | Additional HTTP Status Codes |
| |
| Authors: | M. Nottingham, R. Fielding. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 2616 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6585 |
|
This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. |
|
| |
| RFC 6586 | Experiences from an IPv6-Only Network |
| |
| Authors: | J. Arkko, A. Keranen. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6586 |
|
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. |
|
| |
| RFC 6587 | Transmission of Syslog Messages over TCP |
| |
| Authors: | R. Gerhards, C. Lonvick. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6587 |
|
There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice.This memo describes how TCP has been used as a transport for syslog messages. |
|
| |
| RFC 6588 | A URN Namespace for ucode |
| |
| Authors: | C. Ishikawa. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6588 |
|
This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. |
|
| |
| RFC 6589 | Considerations for Transitioning Content to IPv6 |
| |
| Authors: | J. Livingood. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6589 |
|
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. |
|
| |
| RFC 6590 | Redaction of Potentially Sensitive Data from Mail Abuse Reports |
| |
| Authors: | J. Falk, Ed., M. Kucherawy, Ed.. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6590 |
|
Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. |
|
| |
| RFC 6591 | Authentication Failure Reporting Using the Abuse Reporting Format |
| |
|
|
This memo registers an extension report type for the Abuse ReportingFormat (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. |
|
| |
| RFC 6592 | The Null Packet |
| |
| Authors: | C. Pignataro. |
| Date: | 1 April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6592 |
|
The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. |
|
| |
| RFC 6593 | Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) |
| |
| Authors: | C. Pignataro, J. Clarke, G. Salgueiro. |
| Date: | 1 April 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6593 |
|
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence.Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. |
|
| |
| RFC 6594 | Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records |
| |
| Authors: | O. Sury. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6594 |
|
This document updates the IANA registries in RFC 4255, which definesSSHFP, a DNS Resource Record (RR) that contains a standard SecureShell (SSH) key fingerprint used to verify SSH host keys using DNSSecurity Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic CurveDigital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm inSSHFP Resource Records. |
|
| |
| RFC 6595 | A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) |
| |
| Authors: | K. Wierenga, E. Lear, S. Josefsson. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6595 |
|
The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication andSecurity Layer (SASL) and the Generic Security Service ApplicationProgram Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAMLIdentity Providers with applications using SASL and GSS-API. |
|
| |
| RFC 6596 | The Canonical Link Relation |
| |
| Authors: | M. Ohye, J. Kupke. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6596 |
|
RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship,"canonical", to designate an Internationalized Resource Identifier(IRI) as preferred over resources with duplicative content. |
|
| |
| RFC 6597 | RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data |
| |
| Authors: | J. Downs, Ed., J. Arbeiter, Ed.. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6597 |
|
This document specifies the payload format for packetization of KLV(Key-Length-Value) Encoded Data, as defined by the Society of MotionPicture and Television Engineers (SMPTE) in SMPTE ST 336, into theReal-time Transport Protocol (RTP). |
|
| |
| RFC 6598 | IANA-Reserved IPv4 Prefix for Shared Address Space |
| |
| Authors: | J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 5735 |
| Also: | BCP 0153 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 6598 |
|
This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks.However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.
This document details the allocation of an additional special-useIPv4 address block and updates RFC 5735. |
|
