| |
| RFC 4601 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.
This document obsoletes RFC 2362, an Experimental version of PIM-SM. |
|
| |
| RFC 4602 | Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis |
| |
| Authors: | T. Pusateri. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4602 |
|
This document provides supporting documentation to advance theProtocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. |
|
| |
| RFC 4603 | Additional Values for the NAS-Port-Type Attribute |
| |
| Authors: | G. Zorn, G. Weber, R. Foltak. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4603 |
|
This document defines a set of values for the NAS-Port-Type RADIUSAttribute. |
|
| |
| RFC 4604 | Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast |
| |
|
|
The Internet Group Management Protocol Version 3 (IGMPv3) and theMulticast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively.Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an"SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. |
|
| |
| RFC 4605 | Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") |
| |
| Authors: | B. Fenner, H. He, B. Haberman, H. Sandick. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4605 |
|
In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol(IGMP) or Multicast Listener Discovery (MLD) membership information. |
|
| |
| RFC 4606 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
|
|
This document provides minor clarification to RFC 3946.
This document is a companion to the Generalized Multi-protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology- specific information needed when GMPLS signaling is used. |
|
| |
| RFC 4607 | Source-Specific Multicast for IP |
| |
| Authors: | H. Holbrook, B. Cain. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4607 |
|
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast(SSM) destination addresses and are reserved for use by source- specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. |
|
| |
| RFC 4608 | Source-Specific Protocol Independent Multicast in 232/8 |
| |
| Authors: | D. Meyer, R. Rockell, G. Shepherd. |
| Date: | August 2006 |
| Formats: | txt html json |
| Also: | BCP 0120 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4608 |
|
IP Multicast group addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. |
|
| |
| RFC 4609 | Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements |
| |
| Authors: | P. Savola, R. Lehtonen, D. Meyer. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4609 |
|
This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only ProtocolIndependent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast(ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. |
|
| |
| RFC 4610 | Anycast-RP Using Protocol Independent Multicast (PIM) |
| |
| Authors: | D. Farinacci, Y. Cai. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4610 |
|
This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only.Other multicast protocols (such as Multicast Source DiscoveryProtocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. |
|
| |
| RFC 4611 | Multicast Source Discovery Protocol (MSDP) Deployment Scenarios |
| |
| Authors: | M. McBride, J. Meylor, D. Meyer. |
| Date: | August 2006 |
| Formats: | txt html json |
| Also: | BCP 0121 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4611 |
|
This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode(PIM-SM). |
|
| |
| RFC 4612 | Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration |
| |
| Authors: | P. Jones, H. Tamura. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4612 |
|
This document defines the MIME sub-type audio/t38. The usage of thisMIME type, which is intended for use within Session DescriptionProtocol (SDP), is specified within ITU-T Recommendation T.38. |
|
| |
| RFC 4613 | Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) |
| |
| Authors: | P. Frojdh, U. Lindgren, M. Westerlund. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4613 |
|
This document serves to register a media type for DownloadableSounds. |
|
| |
| RFC 4614 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7414 |
| Updated by: | RFC 6247 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4614 |
|
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. |
|
| |
| RFC 4615 | The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | J. Song, R. Poovendran, J. Lee, T. Iwata. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4615 |
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced EncryptionStandard (AES). This memo describes such an algorithm, calledAES-CMAC-PRF-128. It supports fixed and variable key sizes. |
|
| |
| RFC 4616 | The PLAIN Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
This document defines a simple clear-text user/password SimpleAuthentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. |
|
| |
| RFC 4617 | A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project |
| |
| Authors: | J. Kornijenko. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4617 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian NationalGovernment Integration Project (Latvian abbreviation IVIS). |
|
| |
| RFC 4618 | Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks |
| |
| Authors: | L. Martini, E. Rosen, G. Heron, A. Malis. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4618 |
|
A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over aMultiprotocol Label Switching (MPLS) network without terminating thePPP/HDLC protocol. This enables service providers to offer"emulated" HDLC, or PPP link services over existing MPLS networks.This document specifies the encapsulation of PPP/HDLC Packet DataUnits (PDUs) within a pseudowire. |
|
| |
| RFC 4619 | Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks |
| |
| Authors: | L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4619 |
|
A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network(PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. |
|
| |
| RFC 4620 | IPv6 Node Information Queries |
| |
| Authors: | M. Crawford, B. Haberman, Ed.. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4620 |
|
This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. |
|
| |
| RFC 4621 | Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol |
| |
| Authors: | T. Kivinen, H. Tschofenig. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4621 |
|
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsecSecurity Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. |
|
| |
| RFC 4622 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP). |
|
| |
| RFC 4623 | Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly |
| |
| Authors: | A. Malis, M. Townsley. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4623 |
|
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. |
|
| |
| RFC 4624 | Multicast Source Discovery Protocol (MSDP) MIB |
| |
| Authors: | B. Fenner, D. Thaler. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4624 |
|
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC3618) speakers. |
|
| |
| RFC 4625 | Fibre Channel Routing Information MIB |
| |
| Authors: | C. DeSanti, K. McCloghrie, S. Kode, S. Gai. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4625 |
|
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 managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. |
|
| |
| RFC 4626 | MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol |
| |
| Authors: | C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4626 |
|
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 managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. |
|
| |
| RFC 4627 | The application/json Media Type for JavaScript Object Notation (JSON) |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. |
|
| |
| RFC 4628 | RTP Payload Format for H.263 Moving RFC 2190 to Historic Status |
| |
| Authors: | R. Even. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4628 |
|
The first RFC that describes RTP payload format for ITUTelecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. |
|
| |
| RFC 4629 | RTP Payload Format for ITU-T Rec |
| |
| Authors: | H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. |
| Date: | January 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2429 |
| Updates: | RFC 3555 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4629 |
|
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
The document also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.263 video codec.
The document obsoletes RFC 2429 and updates the H263-1998 andH263-2000 MIME media type in RFC 3555. |
|
| |
| RFC 4630 | Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document updates the handling of DirectoryString in the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding.The requirement for exclusive use of UTF8String after December 31,2003 is removed. |
|
| |
| RFC 4631 | Link Management Protocol (LMP) Management Information Base (MIB) |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 4327 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4631 |
|
This document provides minor corrections to and obsoletes RFC 4327.
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 managed objects for modeling the LinkManagement Protocol (LMP). |
|
| |
| RFC 4632 | Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan |
| |
|
|
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.This document obsoletes the original Classless Inter-domain Routing(CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. |
|
| |
| RFC 4633 | Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists |
| |
|
|
Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managingInternet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. |
|
| |
| RFC 4634 | US Secure Hash Algorithms (SHA and HMAC-SHA) |
| |
|
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), specifically SHA-224 (RFC3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. |
|
| |
| RFC 4635 | HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers |
| |
|
|
Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.Currently, identifiers have been specified only for HMAC MD5 (HashedMessage Authentication Code, Message Digest 5) and GSS (GenericSecurity Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA(Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. |
|
| |
| RFC 4636 | Foreign Agent Error Extension for Mobile IPv4 |
| |
|
|
This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. |
|
| |
| RFC 4638 | Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) |
| |
| Authors: | P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4638 |
|
The Point-to-Point Protocol over Ethernet (PPPoE), as described inRFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. |
|
| |
| RFC 4639 | Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of Data OverCable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.
This memo obsoletes RFC 2669. |
|
| |
| RFC 4640 | Problem Statement for bootstrapping Mobile IPv6 (MIPv6) |
| |
| Authors: | A. Patel, Ed., G. Giaretta, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4640 |
|
A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6(MIPv6) and various potential deployment scenarios for mobile node bootstrapping. |
|
| |
| RFC 4641 | DNSSEC Operational Practices |
| |
|
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. |
|
| |
| RFC 4642 | Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |
| |
|
|
This memo defines an extension to the Network News Transfer Protocol(NNTP) that allows an NNTP client and server to use Transport LayerSecurity (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. |
|
| |
| RFC 4643 | Network News Transfer Protocol (NNTP) Extension for Authentication |
| |
| Authors: | J. Vinocur, K. Murchison. |
| Date: | October 2006 |
| Formats: | txt html json |
| Updates: | RFC 2980 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4643 |
|
This document defines an extension to the Network News TransferProtocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.
This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates theAUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods.Additionally, this document defines a profile of the SimpleAuthentication and Security Layer (SASL) for NNTP. |
|
| |
| RFC 4644 | Network News Transfer Protocol (NNTP) Extension for Streaming Feeds |
| |
| Authors: | J. Vinocur, K. Murchison. |
| Date: | October 2006 |
| Formats: | txt json html |
| Updates: | RFC 2980 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4644 |
|
This memo defines an extension to the Network News Transfer Protocol(NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.
This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. |
|
| |
| RFC 4645 | Initial Language Subtag Registry |
| |
| Authors: | D. Ewell. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4645 |
|
This memo defined the initial contents of the IANA Language SubtagRegistry for use in forming tags for the identification of languages.Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. |
|
| |
| RFC 4646 | Tags for Identifying Languages |
| |
|
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. |
|
| |
| RFC 4647 | Matching of Language Tags |
| |
|
|
This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag.Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC3066, which replaced RFC 1766. |
|
| |
| RFC 4648 | The Base16, Base32, and Base64 Data Encodings |
| |
|
|
This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. |
|
| |
| RFC 4649 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option |
| |
| Authors: | B. Volz. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4649 |
|
This memo defines a new Relay Agent Remote-ID option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). This option is theDHCPv6 equivalent for the Dynamic Host Configuration Protocol forIPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. |
|
| |
| RFC 4650 | HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | M. Euchner. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4650 |
|
This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocolMIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. |
|
| |
| RFC 4651 | A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization |
| |
| Authors: | C. Vogt, J. Arkko. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4651 |
|
This document describes and evaluates strategies to enhance MobileIPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts)Research Group. |
|
| |
| RFC 4652 | Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements |
| |
| Authors: | D. Papadimitriou, Ed., L. Ong, J. Sadler, S. Shew, D. Ward. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4652 |
|
The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) and Optical Transport Networks (OTNs).
This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically SwitchedOptical Network (ASON) as defined by ITU-T. |
|
| |
| RFC 4653 | Improving the Robustness of TCP to Non-Congestion Events |
| |
| Authors: | S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4653 |
|
This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. |
|
| |
| RFC 4654 | TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification |
| |
| Authors: | J. Widmer, M. Handley. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4654 |
|
This document specifies TCP-Friendly Multicast Congestion Control(TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. |
|
| |
| RFC 4655 | A Path Computation Element (PCE)-Based Architecture |
| |
| Authors: | A. Farrel, J.-P. Vasseur, J. Ash. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4655 |
|
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
This document specifies the architecture for a Path ComputationElement (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. |
|
| |
| RFC 4656 | A One-way Active Measurement Protocol (OWAMP) |
| |
|
|
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources(such as GPS and CDMA). OWAMP enables the interoperability of these measurements. |
|
| |
| RFC 4657 | Path Computation Element (PCE) Communication Protocol Generic Requirements |
| |
| Authors: | J. Ash, Ed., J.L. Le Roux, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4657 |
|
The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients(PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs andPCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. |
|
| |
| RFC 4659 | BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN |
| |
| Authors: | J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4659 |
|
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6.In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines anIPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".
This document defines support of the IPv6 VPN service over both anIPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic RoutingEncapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. |
|
| |
| RFC 4660 | Functional Description of Event Notification Filtering |
| |
| Authors: | H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. |
| Date: | September 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6665 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4660 |
|
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. |
|
| |
| RFC 4661 | An Extensible Markup Language (XML)-Based Format for Event Notification Filtering |
| |
| Authors: | H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4661 |
|
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. |
|
| |
| RFC 4662 | A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists |
| |
| Authors: | A. B. Roach, B. Campbell, J. Rosenberg. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4662 |
|
This document presents an extension to the Session InitiationProtocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. |
|
| |
| RFC 4663 | Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG |
| |
| Authors: | D. Harrington. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4663 |
|
This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. |
|
| |
| RFC 4664 | Framework for Layer 2 Virtual Private Networks (L2VPNs) |
| |
| Authors: | L. Andersson, Ed., E. Rosen, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4664 |
|
This document provides a framework for Layer 2 Provider ProvisionedVirtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperableL2VPNs. |
|
| |
| RFC 4665 | Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks |
| |
| Authors: | W. Augustyn, Ed., Y. Serbest, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4665 |
|
This document provides requirements for Layer 2 Provider-ProvisionedVirtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private WireService (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. |
|
| |
| RFC 4666 | Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) |
| |
| Authors: | K. Morneault, Ed., J. Pastor-Balbas, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 3332 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4666 |
|
This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between two IP- based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. This document obsoletesRFC 3332. |
|
| |
| RFC 4667 | Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) |
| |
| Authors: | W. Luo. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4667 |
|
The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types ofL2VPNs in a unified fashion. |
|
| |
| RFC 4668 | RADIUS Authentication Client MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.
This memo obsoletes RFC 2618 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2618 are carried forward into this document. The memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4669 | RADIUS Authentication Server MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.
This memo obsoletes RFC 2619 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2619 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4670 | RADIUS Accounting Client MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting clients.
This memo obsoletes RFC 2620 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2620 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4671 | RADIUS Accounting Server MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting servers.
This memo obsoletes RFC 2621 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2621 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4672 | RADIUS Dynamic Authorization Client MIB |
| |
| Authors: | S. De Cnodder, N. Jonnala, M. Chiba. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4672 |
|
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 the Remote Authentication Dial-In UserService (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. |
|
| |
| RFC 4673 | RADIUS Dynamic Authorization Server MIB |
| |
| Authors: | S. De Cnodder, N. Jonnala, M. Chiba. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4673 |
|
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 the Remote Authentication Dial-In UserService (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. |
|
| |
| RFC 4674 | Requirements for Path Computation Element (PCE) Discovery |
| |
| Authors: | J.L. Le Roux, Ed.. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4674 |
|
This document presents a set of requirements for a Path ComputationElement (PCE) discovery mechanism that would allow a Path ComputationClient (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. |
|
| |
| RFC 4675 | RADIUS Attributes for Virtual LAN and Priority Support |
| |
| Authors: | P. Congdon, M. Sanchez, B. Aboba. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4675 |
|
This document proposes additional Remote Authentication Dial-In UserService (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS orDiameter. |
|
| |
| RFC 4676 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
|
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4677 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
|
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. |
|
| |
| RFC 4678 | Server/Application State Protocol v1 |
| |
| Authors: | A. Bivens. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4678 |
|
Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. TheServer/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. |
|
| |
| RFC 4679 | DSL Forum Vendor-Specific RADIUS Attributes |
| |
| Authors: | V. Mammoliti, G. Zorn, P. Arberg, R. Rennison. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4679 |
|
This document describes the set of Remote Authentication Dial-In UserService Vendor-Specific Attributes (RADIUS VSAs) defined by the DSLForum.
These attributes are designed to transport Digital Subscriber Line(DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. |
|
| |
| RFC 4680 | TLS Handshake Message for Supplemental Data |
| |
|
|
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both theTLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. |
|
| |
| RFC 4681 | TLS User Mapping Extension |
| |
|
|
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. |
|
| |
| RFC 4682 | Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | E. Nechamkin, J-F. Mule. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4682 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
| |
| RFC 4683 | Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) |
| |
| Authors: | J. Park, J. Lee, H. Lee, S. Park, T. Polk. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4683 |
|
This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. |
|
| |
| RFC 4684 | Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) |
| |
| Authors: | P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updates: | RFC 4364 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4684 |
|
This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information.This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN)Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. |
|
| |
| RFC 4685 | Atom Threading Extensions |
| |
| Authors: | J. Snell. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4685 |
|
This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. |
|
| |
| RFC 4686 | Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) |
| |
| Authors: | J. Fenton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4686 |
|
This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. |
|
| |
| RFC 4687 | Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks |
| |
| Authors: | S. Yasukawa, A. Farrel, D. King, T. Nadeau. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4687 |
|
Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. |
|
| |
| RFC 4688 | A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D |
| |
| Authors: | S. Rushing. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4688 |
|
This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and DefenceIndustries Association of Europe (ASD) Specification 1000D. |
|
| |
| RFC 4689 | Terminology for Benchmarking Network-layer Traffic Control Mechanisms |
| |
| Authors: | S. Poretsky, J. Perser, S. Erramilli, S. Khurana. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4689 |
|
This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms.Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. |
|
| |
| RFC 4690 | Review and Recommendations for Internationalized Domain Names (IDNs) |
| |
| Authors: | J. Klensin, P. Faltstrom, C. Karp, IAB. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4690 |
|
This note describes issues raised by the deployment and use ofInternationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for theInternationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. |
|
| |
| RFC 4691 | Guidelines for Acting as an IETF Liaison to Another Organization |
| |
| Authors: | L. Andersson, Ed.. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4691 |
|
Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization(SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. |
|
| |
| RFC 4692 | Considerations on the IPv6 Host Density Metric |
| |
| Authors: | G. Huston. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4692 |
|
This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. |
|
| |
| RFC 4693 | IETF Operational Notes |
| |
|
|
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
It proposes to establish this series as an RFC 3933 process experiment. |
|
| |
| RFC 4694 | Number Portability Parameters for the "tel" URI |
| |
| Authors: | J. Yu. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4694 |
|
This document defines five parameters in the "tel" Uniform ResourceIdentifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. |
|
| |
| RFC 4695 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6295 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4695 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. |
|
| |
| RFC 4696 | An Implementation Guide for RTP MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4696 |
|
This memo offers non-normative implementation guidance for the Real- time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room.Underlying the performances are RTP MIDI sessions over unicast UDP.Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail.Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. |
|
| |
| RFC 4697 | Observed DNS Resolution Misbehavior |
| |
|
|
This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. |
|
| |
| RFC 4698 | IRIS: An Address Registry (areg) Type for the Internet Registry Information Service |
| |
| Authors: | E. Gunduz, A. Newton, S. Kerr. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4698 |
|
This document describes an IRIS registry schema for IP address andAutonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used byInternet Protocol address registries. |
|
