| |
| RFC 5501 | Requirements for Multicast Support in Virtual Private LAN Services |
| |
| Authors: | Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5501 |
|
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. |
|
| |
| RFC 5502 | The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem |
| |
|
|
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd GenerationPartnership Project (3GPP) IMS (IP Multimedia Subsystem) between anS-CSCF (Serving Call Session Control Function) and an AS (ApplicationServer) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. |
|
| |
| RFC 5503 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | F. Andreasen, B. McKibben, B. Marshall. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoletes: | RFC 3603 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5503 |
|
In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 5504 | Downgrading Mechanism for Email Address Internationalization |
| |
| Authors: | K. Fujiwara, Ed., Y. Yoneya, Ed.. |
| Date: | March 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6530 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5504 |
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. |
|
| |
| RFC 5505 | Principles of Internet Host Configuration |
| |
| Authors: | B. Aboba, D. Thaler, L. Andersson, S. Cheshire. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5505 |
|
This document describes principles of Internet host configuration.It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. |
|
| |
| RFC 5506 | Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences |
| |
|
|
This memo discusses benefits and issues that arise when allowingReal-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time TransportProtocol / Audio-Visual Profile with Feedback) profile (RFC 4585).This document updates RFC 3550, RFC 3711, and RFC 4585. |
|
| |
| RFC 5507 | Design Choices When Expanding the DNS |
| |
| Authors: | IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5507 |
|
This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNSResource Record Type is the best solution. |
|
| |
| RFC 5508 | NAT Behavioral Requirements for ICMP |
| |
| Authors: | P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0148 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5508 |
|
This document specifies the behavioral properties required of theNetwork Address Translator (NAT) devices in conjunction with theInternet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. |
|
| |
| RFC 5509 | Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) |
| |
| Authors: | S. Loreto. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5509 |
|
This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. |
|
| |
| RFC 5510 | Reed-Solomon Forward Error Correction (FEC) Schemes |
| |
| Authors: | J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5510 |
|
This document describes a Fully-Specified Forward Error Correction(FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-SpecifiedFEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC EncodingID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable(MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. |
|
| |
| RFC 5511 | Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications |
| |
| Authors: | A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5511 |
|
Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.
There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.
Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.
This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. |
|
| |
| RFC 5512 | The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute |
| |
| Authors: | P. Mohapatra, E. Rosen. |
| Date: | April 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5512 |
|
In certain situations, transporting a packet from one Border GatewayProtocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the"encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such asLayer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic RoutingEncapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using theEncapsulation Subsequent Address Family Identifier (SAFI) and theIPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. |
|
| |
| RFC 5513 | IANA Considerations for Three Letter Acronyms |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5513 |
|
Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions.While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of theInternet as misunderstandings lead to misconfiguration or other operating errors.
Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. |
|
| |
| RFC 5514 | IPv6 over Social Networks |
| |
| Authors: | E. Vyncke. |
| Date: | 1 April 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5514 |
|
There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.This will immediately add millions of IPv6 hosts to the existing IPv6Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. |
|
| |
| RFC 5515 | Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions |
| |
| Authors: | V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5515 |
|
This document describes a set of Layer 2 Tunneling Protocol (L2TP)Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. TheL2TP AVPs defined in this document are applicable to both L2TPv2 andL2TPv3. |
|
| |
| RFC 5516 | Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) |
| |
| Authors: | M. Jones, L. Morand. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5516 |
|
This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for theThird Generation Partnership Project (3GPP) Evolved Packet System(EPS). These new Diameter applications are defined for MobileManagement Entity (MME)- and Serving GPRS (General Packet RadioService) Support Node (SGSN)-related interfaces in in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). |
|
| |
| RFC 5517 | Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment |
| |
| Authors: | S. HomChaudhuri, M. Foschiano. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5517 |
|
This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints.Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.
Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. |
|
| |
| RFC 5518 | Vouch By Reference |
| |
| Authors: | P. Hoffman, J. Levine, A. Hathcock. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5518 |
|
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. |
|
| |
| RFC 5519 | Multicast Group Membership Discovery MIB |
| |
|
|
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 objects used for managing the InternetGroup Management Protocol (IGMP) and the Multicast Listener Discovery(MLD) protocol. |
|
| |
| RFC 5520 | Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism |
| |
| Authors: | R. Bradford, Ed., JP. Vasseur, A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5520 |
|
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., whenASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information.This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LabelSwitching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.
This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCECommunication Protocol (PCEP) and signaled within in a ResourceReservation Protocol TE (RSVP-TE) explicit route object. |
|
| |
| RFC 5521 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions |
| |
| Authors: | E. Oki, T. Takeda, A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5521 |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups(SRLGs) that are to be explicitly excluded from the computed route.Such constraints are termed "route exclusions".
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. |
|
| |
| RFC 5522 | Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks |
| |
| Authors: | W. Eddy, W. Ivancic, T. Davis. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5522 |
|
This document describes the requirements and desired properties ofNetwork Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.
Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of theInternational Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. |
|
| |
| RFC 5523 | OSPFv3-Based Layer 1 VPN Auto-Discovery |
| |
| Authors: | L. Berger. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5523 |
|
This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. |
|
| |
| RFC 5524 | Extended URLFETCH for Binary and Converted Parts |
| |
| Authors: | D. Cridland. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5524 |
|
The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. |
|
| |
| RFC 5525 | Reliable Server Pooling MIB Module Definition |
| |
| Authors: | T. Dreibholz, J. Mulik. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5525 |
|
Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols:ASAP (Aggregate Server Access Protocol) and ENRP (EndpointHandlespace Redundancy Protocol). This document defines an SMIv2- compliant (Structure of Management Information Version 2) ManagementInformation Base (MIB) module providing access to managed objects in an RSerPool implementation. |
|
| |
| RFC 5526 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM |
| |
| Authors: | J. Livingood, P. Pfautz, R. Stastny. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5526 |
|
This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). |
|
| |
| RFC 5527 | Combined User and Infrastructure ENUM in the e164.arpa Tree |
| |
| Authors: | M. Haberler, O. Lendl, R. Stastny. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5527 |
|
This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. |
|
| |
| RFC 5528 | Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5528 |
|
This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. |
|
| |
| RFC 5529 | Modes of Operation for Camellia for Use with IPsec |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5529 |
|
This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) andEncapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. |
|
| |
| RFC 5530 | IMAP Response Codes |
| |
| Authors: | A. Gulbrandsen. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5530 |
|
IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.
This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. |
|
| |
| RFC 5531 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
|
|
This document describes the Open Network Computing (ONC) RemoteProcedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. |
|
| |
| RFC 5532 | Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement |
| |
| Authors: | T. Talpey, C. Juszczak. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5532 |
|
This document addresses enabling the use of Remote Direct MemoryAccess (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead.This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. |
|
| |
| RFC 5533 | Shim6: Level 3 Multihoming Shim Protocol for IPv6 |
| |
| Authors: | E. Nordmark, M. Bagnulo. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5533 |
|
This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. |
|
| |
| RFC 5534 | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming |
| |
| Authors: | J. Arkko, I. van Beijnum. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5534 |
|
This document specifies how the level 3 multihoming Shim6 protocol(Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. |
|
| |
| RFC 5535 | Hash-Based Addresses (HBA) |
| |
| Authors: | M. Bagnulo. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5535 |
|
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs eitherCryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. |
|
| |
| RFC 5536 | Netnews Article Format |
| |
|
|
This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose InternetMail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. |
|
| |
| RFC 5537 | Netnews Architecture and Protocols |
| |
|
|
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. |
|
| |
| RFC 5538 | The 'news' and 'nntp' URI Schemes |
| |
| Authors: | F. Ellermann. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5538 |
|
This memo specifies the 'news' and 'nntp' Uniform Resource Identifier(URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. |
|
| |
| RFC 5539 | NETCONF over Transport Layer Security (TLS) |
| |
|
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. |
|
| |
| RFC 5540 | 40 Years of RFCs |
| |
|
|
This RFC marks the 40th anniversary of the RFC document series. |
|
| |
| RFC 5541 | Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | JL. Le Roux, JP. Vasseur, Y. Lee. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5541 |
|
The computation of one or a set of Traffic Engineering Label SwitchedPaths (TE LSPs) in MultiProtocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions(e.g., minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a PathComputation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, thePCC needs to instruct the PCE to use the correct objective function.Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.
This document defines extensions to the PCE communication Protocol(PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.
This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. |
|
| |
| RFC 5542 | Definitions of Textual Conventions for Pseudowire (PW) Management |
| |
| Authors: | T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed.. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5542 |
|
This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 5543 | BGP Traffic Engineering Attribute |
| |
| Authors: | H. Ould-Brahim, D. Fedyk, Y. Rekhter. |
| Date: | May 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5543 |
|
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. |
|
| |
| RFC 5544 | Syntax for Binding Documents with Time-Stamps |
| |
|
|
This document describes an envelope that can be used to bind a file(not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors.Additional types of temporal evidence are also allowed.
The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. |
|
| |
| RFC 5545 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
|
| |
| RFC 5546 | iCalendar Transport-Independent Interoperability Protocol (iTIP) |
| |
|
|
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. |
|
| |
| RFC 5547 | A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer |
| |
| Authors: | M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5547 |
|
This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session DescriptionProtocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred.The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation.The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. |
|
| |
| RFC 5548 | Routing Requirements for Urban Low-Power and Lossy Networks |
| |
| Authors: | M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5548 |
|
The application-specific routing requirements for Urban Low-Power andLossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws.These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-powerIEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. |
|
| |
| RFC 5549 | Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop |
| |
| Authors: | F. Le Faucheur, E. Rosen. |
| Date: | May 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5549 |
|
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and theSubsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowingMP-BGP Peers to dynamically discover whether they can exchange IPv4NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. |
|
| |
| RFC 5550 | The Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
|
|
This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients(especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP andSubmission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. |
|
| |
| RFC 5551 | Lemonade Notifications Architecture |
| |
| Authors: | R. Gellens, Ed.. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5551 |
|
Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) WorkingGroup.
This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. |
|
| |
| RFC 5552 | SIP Interface to VoiceXML Media Services |
| |
| Authors: | D. Burke, M. Scott. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5552 |
|
This document describes a SIP interface to VoiceXML media services.Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. |
|
| |
| RFC 5553 | Resource Reservation Protocol (RSVP) Extensions for Path Key Support |
| |
| Authors: | A. Farrel, Ed., R. Bradford, JP. Vasseur. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5553 |
|
The paths taken by Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Traffic Engineering (TE) Label SwitchedPaths (LSPs) may be computed by Path Computation Elements (PCEs).Where the TE LSP crosses multiple domains, such as Autonomous Systems(ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.
To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called theConfidential Path Segment (CPS), by encoding the contents as a PathKey Subobject (PKS) and embedding this subobject within the result of its path computation.
This document describes how to carry Path Key Subobjects in theResource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. |
|
| |
| RFC 5554 | Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings |
| |
|
|
This document clarifies and generalizes the Generic Security ServiceApplication Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. |
|
| |
| RFC 5555 | Mobile IPv6 Support for Dual Stack Hosts and Routers |
| |
|
|
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where NetworkAddress Translation is present on the path between the mobile node and its home agent. |
|
| |
| RFC 5556 | Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement |
| |
| Authors: | J. Touch, R. Perlman. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5556 |
|
Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths(in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with802.1, including hubs, bridges, and their existing plug-and-play capabilities. |
|
| |
| RFC 5557 | Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization |
| |
| Authors: | Y. Lee, JL. Le Roux, D. King, E. Oki. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5557 |
|
The Path Computation Element Communication Protocol (PCEP) allowsPath Computation Clients (PCCs) to request path computations fromPath Computation Elements (PCEs), and lets the PCEs return responses.When computing or reoptimizing the routes of a set of TrafficEngineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions.Such bulk optimization is termed Global Concurrent Optimization(GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.
This document provides application-specific requirements and the PCEP extensions in support of GCO applications. |
|
| |
| RFC 5558 | Virtual Enterprise Traversal (VET) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5558 |
|
Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet.Enterprise network nodes require a means to automatically provisionIP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. |
|
| |
| RFC 5559 | Pre-Congestion Notification (PCN) Architecture |
| |
| Authors: | P. Eardley, Ed.. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5559 |
|
This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. |
|
| |
| RFC 5560 | A One-Way Packet Duplication Metric |
| |
|
|
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.
In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. |
|
| |
| RFC 5561 | LDP Capabilities |
| |
| Authors: | B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5561 |
|
A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements afterLDP session establishment. |
|
| |
| RFC 5562 | Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets |
| |
| Authors: | A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5562 |
|
The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ExplicitCongestion Notification (ECN) in TCP SYN/ACK packets.
This document describes an optional, experimental modification to RFC3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use ofECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet asECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder(the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). |
|
| |
| RFC 5563 | WiMAX Forum / 3GPP2 Proxy Mobile IPv4 |
| |
| Authors: | K. Leung, G. Dommety, P. Yegani, K. Chowdhury. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5563 |
|
Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility- unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. |
|
| |
| RFC 5564 | Linguistic Guidelines for the Use of the Arabic Language in Internet Domains |
| |
| Authors: | A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5564 |
|
This document constitutes technical specifications for the use ofArabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. |
|
| |
| RFC 5565 | Softwire Mesh Framework |
| |
| Authors: | J. Wu, Y. Cui, C. Metz, E. Rosen. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5565 |
|
The Internet needs to be able to handle both IPv4 and IPv6 packets.However, it is expected that some constituent networks of theInternet will be "single-protocol" networks. One kind of single- protocol network can parse only IPv4 packets and can process onlyIPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. |
|
| |
| RFC 5566 | BGP IPsec Tunnel Encapsulation Attribute |
| |
| Authors: | L. Berger, R. White, E. Rosen. |
| Date: | June 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5566 |
|
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for GenericRouting Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), andIP in IP tunnel types are defined. This document defines support forIPsec tunnel types. |
|
| |
| RFC 5567 | An Architectural Framework for Media Server Control |
| |
| Authors: | T. Melanchuk, Ed.. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5567 |
|
This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. |
|
| |
| RFC 5568 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures(namely, movement detection, new Care-of Address configuration, andBinding Update) is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.
This document updates the packet formats for the Handover Initiate(HI) and Handover Acknowledge (HAck) messages to the Mobility HeaderType. |
|
| |
| RFC 5569 | IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) |
| |
| Authors: | R. Despres. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5569 |
|
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deployIPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. |
|
| |
| RFC 5570 | Common Architecture Label IPv6 Security Option (CALIPSO) |
| |
| Authors: | M. StJohns, R. Atkinson, G. Thomas. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5570 |
|
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. |
|
| |
| RFC 5571 | Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) |
| |
| Authors: | B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5571 |
|
This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2).The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. |
|
| |
| RFC 5572 | IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) |
| |
| Authors: | M. Blanchet, F. Parent. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5572 |
|
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 orIPv4, inside various outer protocols packets, such as IPv4, IPv6, orUDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. |
|
| |
| RFC 5573 | Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) |
| |
| Authors: | M. Thomson. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5573 |
|
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. |
|
| |
| RFC 5574 | RTP Payload Format for the Speex Codec |
| |
| Authors: | G. Herlein, J. Valin, A. Heggestad, A. Moizard. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5574 |
|
Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with theSession Description Protocol (SDP). |
|
| |
| RFC 5575 | Dissemination of Flow Specification Rules |
| |
| Authors: | P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8955 |
| Updated by: | RFC 7674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5575 |
|
This document defines a new Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate(distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. |
|
| |
| RFC 5576 | Source-Specific Media Attributes in the Session Description Protocol (SDP) |
| |
| Authors: | J. Lennox, J. Ott, T. Schierl. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5576 |
|
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, inSDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. |
|
| |
| RFC 5577 | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of theSession Description Protocol (SDP) parameters needed to supportG.722.1 audio codec. |
|
| |
| RFC 5578 | PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
| Authors: | B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams. |
| Date: | February 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 4938 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5578 |
|
This document extends the Point-to-Point Protocol over Ethernet(PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. |
|
| |
| RFC 5579 | Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5579 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automaticIPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. |
|
| |
| RFC 5580 | Carrying Location Objects in RADIUS and Diameter |
| |
| Authors: | H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. |
| Date: | August 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8559 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5580 |
|
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service(RADIUS) and Diameter.
The distribution of location information is a privacy-sensitive task.Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. |
|
| |
| RFC 5581 | The Camellia Cipher in OpenPGP |
| |
|
|
This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. |
|
| |
| RFC 5582 | Location-to-URL Mapping Architecture and Framework |
| |
| Authors: | H. Schulzrinne. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5582 |
|
|
|
| |
| RFC 5583 | Signaling Media Decoding Dependency in the Session Description Protocol (SDP) |
| |
| Authors: | T. Schierl, S. Wenger. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5583 |
|
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). |
|
| |
| RFC 5584 | RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family |
| |
| Authors: | M. Hatanaka, J. Matsumoto. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5584 |
|
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the AdaptiveTRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. |
|
| |
| RFC 5585 | DomainKeys Identified Mail (DKIM) Service Overview |
| |
| Authors: | T. Hansen, D. Crocker, P. Hallam-Baker. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5585 |
|
This document provides an overview of the DomainKeys Identified Mail(DKIM) service and describes how it can fit into a messaging service.It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". |
|
| |
| RFC 5586 | MPLS Generic Associated Channel |
| |
| Authors: | M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. |
| Date: | June 2009 |
| Formats: | txt json html |
| Updates: | RFC 3032, RFC 4385, RFC 5085 |
| Updated by: | RFC 6423, RFC 7026, RFC 7214, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5586 |
|
This document generalizes the applicability of the pseudowire (PW)Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) andMPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. |
|
| |
| RFC 5587 | Extended Generic Security Service Mechanism Inquiry APIs |
| |
| Authors: | N. Williams. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5587 |
|
This document introduces new application programming interfaces(APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.
These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. |
|
| |
| RFC 5588 | Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials |
| |
| Authors: | N. Williams. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5588 |
|
This document defines a new function for the Generic Security ServiceApplication Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. |
|
| |
| RFC 5589 | Session Initiation Protocol (SIP) Call Control - Transfer |
| |
| Authors: | R. Sparks, A. Johnston, Ed., D. Petrie. |
| Date: | June 2009 |
| Formats: | txt html json |
| Also: | BCP 0149 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5589 |
|
This document describes providing Call Transfer capabilities in theSession Initiation Protocol (SIP). SIP extensions such as REFER andReplaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. |
|
| |
| RFC 5590 | Transport Subsystem for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document defines a Transport Subsystem, extending the SimpleNetwork Management Protocol (SNMP) architecture defined in RFC 3411.This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security
(TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. |
|
| |
| RFC 5591 | Transport Security Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This memo describes a Transport Security Model for the Simple NetworkManagement Protocol (SNMP).
This memo also defines a portion of the Management Information Base(MIB) for monitoring and managing the Transport Security Model forSNMP. |
|
| |
| RFC 5592 | Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | D. Harrington, J. Salowey, W. Hardaker. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5592 |
|
This memo describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), using the Secure Shell (SSH) protocol.
This memo also defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. |
|
| |
| RFC 5593 | Internet Message Access Protocol (IMAP) - URL Access Identifier Extension |
| |
|
|
The existing IMAP URL specification (RFC 5092) lists several <access&rt; identifiers and <access&rt; identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access&rt; identifiers as well as an IANA mechanism to register new <access&rt; identifiers for future applications.
This document updates RFC 5092. |
|
| |
| RFC 5594 | Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 |
| |
| Authors: | J. Peterson, A. Cooper. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5594 |
|
This document reports the outcome of a workshop organized by theReal-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in theIETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. |
|
| |
| RFC 5595 | The Datagram Congestion Control Protocol (DCCP) Service Codes |
| |
|
|
This document describes the usage of Service Codes by the DatagramCongestion Control Protocol, RFC 4340. It motivates the setting of aService Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC4340. |
|
| |
| RFC 5596 | Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal |
| |
|
|
This document specifies an update to the Datagram Congestion ControlProtocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., aNetwork Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. |
|
| |
| RFC 5597 | Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol |
| |
|
|
This document defines a set of requirements for NATs handling theDatagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements forNATs, which have already been published by the IETF. Ensuring thatNATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. |
|
| |
| RFC 5598 | Internet Mail Architecture |
| |
|
|
Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. |
|
