| |
| RFC 4701 | A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) |
| |
| Authors: | M. Stapp, T. Lemon, A. Gustafsson. |
| Date: | October 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4701 |
|
It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct ResourceRecord (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. |
|
| |
| RFC 4702 | The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option |
| |
| Authors: | M. Stapp, B. Volz, Y. Rekhter. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4702 |
|
This document describes a Dynamic Host Configuration Protocol forIPv4 (DHCPv4) option that can be used to exchange information about aDHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. |
|
| |
| RFC 4703 | Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients |
| |
| Authors: | M. Stapp, B. Volz. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4703 |
|
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names(FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. |
|
| |
| RFC 4704 | The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option |
| |
| Authors: | B. Volz. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4704 |
|
This document specifies a new Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option that can be used to exchange information about aDHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. |
|
| |
| RFC 4705 | GigaBeam High-Speed Radio Link Encryption |
| |
| Authors: | R. Housley, A. Corry. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4705 |
|
This document describes the encryption and key management used byGigaBeam as part of the WiFiber(tm) family of radio link products.The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. |
|
| |
| RFC 4706 | Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) |
| |
| Authors: | M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4706 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the"Asymmetric Digital Subscriber Line" family of interface types: ADSL,ADSL2, ADSL2+, and their variants. |
|
| |
| RFC 4707 | Netnews Administration System (NAS) |
| |
| Authors: | P. Grau, V. Heinau, H. Schlichting, R. Schuettler. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4707 |
|
The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.
The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually.News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.
NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible.Furthermore, NAS is able to reflect the somewhat chaotic structure ofUsenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS- compliant software. |
|
| |
| RFC 4708 | CellML Media Type |
| |
| Authors: | A. Miller. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4708 |
|
This document standardises a new media type -- application/cellml+xml-- for use in exchanging mathematical models represented in a CellMLUmbrella 1.0 compliant markup language. |
|
| |
| RFC 4709 | Mounting Web Distributed Authoring and Versioning (WebDAV) Servers |
| |
| Authors: | J. Reschke. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4709 |
|
In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of aWeb Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.
This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. |
|
| |
| RFC 4710 | Real-time Application Quality-of-Service Monitoring (RAQMON) Framework |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4710 |
|
There is a need to monitor end-devices such as IP phones, pagers,Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring(RMON) family of specifications to allow real-time quality-of-service(QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. |
|
| |
| RFC 4711 | Real-time Application Quality-of-Service Monitoring (RAQMON) MIB |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4711 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.The document proposes an extension to the Remote Monitoring MIB, RFC2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. |
|
| |
| RFC 4712 | Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman, Y. Kim. |
| Date: | October 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4712 |
|
This memo specifies two transport mappings of the Real-TimeApplication Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the SimpleNetwork Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). |
|
| |
| RFC 4713 | Registration and Administration Recommendations for Chinese Domain Names |
| |
| Authors: | X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4713 |
|
Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms.The equivalence between Simplified Chinese (SC) and TraditionalChinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. |
|
| |
| RFC 4714 | Requirements for IETF Technical Publication Service |
| |
| Authors: | A. Mankin, S. Hayes. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4714 |
|
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation.Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. |
|
| |
| RFC 4715 | The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4715 |
|
Without a tel URI parameter to carry an encoding type of IntegratedServices Digital Network (ISDN) subaddress, interworking between ISDNUser Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. |
|
| |
| RFC 4716 | The Secure Shell (SSH) Public Key File Format |
| |
| Authors: | J. Galbraith, R. Thayer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4716 |
|
This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell(SSH) implementations.
In addition, this document defines a standard textual representation for SSH public key fingerprints. |
|
| |
| RFC 4717 | Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks |
| |
| Authors: | L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4717 |
|
An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carryATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. |
|
| |
| RFC 4718 | IKEv2 Clarifications and Implementation Guidelines |
| |
| Authors: | P. Eronen, P. Hoffman. |
| Date: | October 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4718 |
|
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. |
|
| |
| RFC 4719 | Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4719 |
|
This document describes the transport of Ethernet frames over theLayer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport ofEthernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. |
|
| |
| RFC 4720 | Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention |
| |
| Authors: | A. Malis, D. Allan, N. Del Regno. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4720 |
|
This document defines a mechanism for preserving Frame Check Sequence(FCS) through Ethernet, Frame Relay, High-Level Data Link Control(HDLC), and PPP pseudowires. |
|
| |
| RFC 4721 | Mobile IPv4 Challenge/Response Extensions (Revised) |
| |
|
|
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as ChallengeHandshake Authentication Protocol (CHAP)) for authenticating portable computer devices.
In this specification, we define extensions for the Mobile IP AgentAdvertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication,Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. |
|
| |
| RFC 4722 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5022 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4722 |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 4723 | Registration of Media Type audio/mobile-xmf |
| |
| Authors: | T. Kosonen, T. White. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4723 |
|
The MIDI Manufacturers Association (MMA) and the Association ofMusical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. |
|
| |
| RFC 4724 | Graceful Restart Mechanism for BGP |
| |
| Authors: | S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. |
| Date: | January 2007 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Updated by: | RFC 8538 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4724 |
|
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful RestartCapability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). |
|
| |
| RFC 4725 | ENUM Validation Architecture |
| |
| Authors: | A. Mayrhofer, B. Hoeneisen. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4725 |
|
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of anENUM domain name is identical to the Assignee of the correspondingE.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. |
|
| |
| RFC 4726 | A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering |
| |
| Authors: | A. Farrel, J.-P. Vasseur, A. Ayyangar. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4726 |
|
This document provides a framework for establishing and controllingMultiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and AutonomousSystems (ASes). |
|
| |
| RFC 4727 | Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers |
| |
| Authors: | B. Fenner. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4727 |
|
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. |
|
| |
| RFC 4728 | The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 |
| |
| Authors: | D. Johnson, Y. Hu, D. Maltz. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4728 |
|
The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and"Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.Other advantages of the DSR protocol include easily guaranteed loop- free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. |
|
| |
| RFC 4729 | A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum |
| |
| Authors: | M. Abel. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4729 |
|
This document describes the Namespace Identifier (NID) for UniformResource Name (URN) resources published by the Near FieldCommunication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFCForum Technical Committee. |
|
| |
| RFC 4730 | A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) |
| |
| Authors: | E. Burger, M. Dolly. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4730 |
|
This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and usesExtensible Markup Language (XML) documents referred to as Key PressMarkup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in theSession Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses(triggers). |
|
| |
| RFC 4731 | IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9394 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4731 |
|
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. |
|
| |
| RFC 4732 | Internet Denial-of-Service Considerations |
| |
| Authors: | M. Handley, Ed., E. Rescorla, Ed., IAB. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4732 |
|
This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. |
|
| |
| RFC 4733 | RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals |
| |
|
|
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets.It obsoletes RFC 2833.
This memo captures and expands upon the basic framework defined inRFC 2833, but retains only the most basic event codes. It sets up anIANA registry to which other event code assignments may be added.Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events.The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. |
|
| |
| RFC 4734 | Definition of Events for Modem, Fax, and Text Telephony Signals |
| |
|
|
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. |
|
| |
| RFC 4735 | Example Media Types for Use in Documentation |
| |
| Authors: | T. Taylor. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4735 |
|
This document is registration for the 'example' media type and'example' subtypes within the standards tree. The 'example/*' and'*/example' media types are defined for documentation purposes only. |
|
| |
| RFC 4736 | Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) |
| |
| Authors: | JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4736 |
|
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)Traffic Engineering (TE) Label Switched Paths (LSPs) signaled withResource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end LabelSwitching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists(compared to the current path) or that the TE LSP must be reoptimized(because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (InteriorGateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. |
|
| |
| RFC 4737 | Packet Reordering Metrics |
| |
| Authors: | A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4737 |
|
This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included.An appendix gives extended definitions for evaluating order with packet fragmentation. |
|
| |
| RFC 4738 | MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | D. Ignjatic, L. Dondeti, F. Audet, P. Lin. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updates: | RFC 3830 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4738 |
|
The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally aDiffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder'sID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. |
|
| |
| RFC 4739 | Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol |
| |
| Authors: | P. Eronen, J. Korhonen. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4739 |
|
The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and ExtensibleAuthentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by anEAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. |
|
| |
| RFC 4740 | Diameter Session Initiation Protocol (SIP) Application |
| |
| Authors: | M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4740 |
|
This document specifies the Diameter Session Initiation Protocol(SIP) application. This is a Diameter application that allows aDiameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. |
|
| |
| RFC 4741 | NETCONF Configuration Protocol |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. |
|
| |
| RFC 4742 | Using the NETCONF Configuration Protocol over Secure SHell (SSH) |
| |
| Authors: | M. Wasserman, T. Goddard. |
| Date: | December 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6242 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4742 |
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. |
|
| |
| RFC 4743 | Using NETCONF over the Simple Object Access Protocol (SOAP) |
| |
|
|
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of theSimple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange ExtensibleProtocol (BEEP) bindings for NETCONF. |
|
| |
| RFC 4744 | Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
This document specifies an application protocol mapping for theNetwork Configuration Protocol (NETCONF) over the Blocks ExtensibleExchange Protocol (BEEP). |
|
| |
| RFC 4745 | Common Policy: A Document Format for Expressing Privacy Preferences |
| |
| Authors: | H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4745 |
|
This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. |
|
| |
| RFC 4746 | Extensible Authentication Protocol (EAP) Password Authenticated Exchange |
| |
| Authors: | T. Clancy, W. Arbaugh. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4746 |
|
This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. |
|
| |
| RFC 4747 | The Virtual Fabrics MIB |
| |
| Authors: | S. Kipp, G. Ramkumar, K. McCloghrie. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4747 |
|
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 Virtual Fabrics function. |
|
| |
| RFC 4748 | RFC 3978 Update to Recognize the IETF Trust |
| |
|
|
This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of allIETF-related intellectual property rights.
This document does not constrain how the IETF Trust exercises those rights. |
|
| |
| RFC 4749 | RTP Payload Format for the G.729.1 Audio Codec |
| |
|
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. |
|
| |
| RFC 4750 | OSPF Version 2 Management Information Base |
| |
| Authors: | D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed.. |
| Date: | December 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 1850 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4750 |
|
|
|
| |
| RFC 4752 | The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols.This document describes the method for using the Generic SecurityService Application Program Interface (GSS-API) Kerberos V5 in theSASL.
This document replaces Section 7.2 of RFC 2222, the definition of the"GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. |
|
| |
| RFC 4753 | ECP Groups For IKE and IKEv2 |
| |
|
|
This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to alignIKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. |
|
| |
| RFC 4754 | IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) |
| |
| Authors: | D. Fu, J. Solinas. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4754 |
|
This document describes how the Elliptic Curve Digital SignatureAlgorithm (ECDSA) may be used as the authentication method within theInternet Key Exchange (IKE) and Internet Key Exchange version 2(IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods.This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. |
|
| |
| RFC 4755 | IP over InfiniBand: Connected Mode |
| |
| Authors: | V. Kashyap. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4755 |
|
This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. |
|
| |
| RFC 4756 | Forward Error Correction Grouping Semantics in Session Description Protocol |
| |
|
|
This document defines the semantics that allow for grouping ofForward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in theSession Description Protocol" (RFC 3388) to group together "m" lines in the same session. |
|
| |
| RFC 4757 | The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows |
| |
| Authors: | K. Jaganathan, L. Zhu, J. Brezak. |
| Date: | December 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6649 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4757 |
|
The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.
The RC4-HMAC encryption types are used to ease upgrade of existingWindows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. |
|
| |
| RFC 4758 | Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 |
| |
| Authors: | M. Nystroem. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4758 |
|
This document constitutes Revision 1 of Cryptographic Token KeyInitialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories'One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.
CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. |
|
| |
| RFC 4759 | The ENUM Dip Indicator Parameter for the "tel" URI |
| |
| Authors: | R. Stastny, R. Shockey, L. Conroy. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4759 |
|
This document defines a new parameter "enumdi" for the "tel" UniformResource Identifier (URI) to support the handling of ENUM queries inVoice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if aVoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. |
|
| |
| RFC 4760 | Multiprotocol Extensions for BGP-4 |
| |
|
|
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6,IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. |
|
| |
| RFC 4761 | Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling |
| |
|
|
Virtual Private LAN Service (VPLS), also known as Transparent LANService and Virtual Private Switched Network service, is a usefulService Provider offering. The service offers a Layer 2 VirtualPrivate Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. |
|
| |
| RFC 4762 | Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling |
| |
| Authors: | M. Lasserre, Ed., V. Kompella, Ed.. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4762 |
|
This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS).A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.
This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extendingRFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. |
|
| |
| RFC 4763 | Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) |
| |
| Authors: | M. Vanderveen, H. Soliman. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4763 |
|
This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment(SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748.The specification has passed Designated Expert review for this IANA assignment. |
|
| |
| RFC 4764 | The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method |
| |
| Authors: | F. Bersani, H. Tschofenig. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4764 |
|
This document specifies EAP-PSK, an Extensible AuthenticationProtocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. |
|
| |
| RFC 4765 | The Intrusion Detection Message Exchange Format (IDMEF) |
| |
| Authors: | H. Debar, D. Curry, B. Feinstein. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4765 |
|
The purpose of the Intrusion Detection Message Exchange Format(IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.
This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in theExtensible Markup Language (XML) is presented, an XML Document TypeDefinition is developed, and examples are provided. |
|
| |
| RFC 4766 | Intrusion Detection Message Exchange Requirements |
| |
| Authors: | M. Wood, M. Erlinger. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4766 |
|
The purpose of the Intrusion Detection Exchange Format Working Group(IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. |
|
| |
| RFC 4767 | The Intrusion Detection Exchange Protocol (IDXP) |
| |
| Authors: | B. Feinstein, G. Matthews. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4767 |
|
This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described inRFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange FormatWorking Group (IDWG) of the IETF. |
|
| |
| RFC 4768 | Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming |
| |
| Authors: | S. Hartman. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4768 |
|
The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions.Advances in security mechanisms and the way implementers wish to useGSS-API require this model to be extended for the next version ofGSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. |
|
| |
| RFC 4769 | IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information |
| |
| Authors: | J. Livingood, R. Shockey. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4769 |
|
This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using theURI scheme 'sip' as per the IANA registration process defined in theENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. |
|
| |
| RFC 4770 | vCard Extensions for Instant Messaging (IM) |
| |
| Authors: | C. Jennings, J. Reschke, Ed.. |
| Date: | January 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4770 |
|
This document describes an extension to vCard to support InstantMessaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. |
|
| |
| RFC 4771 | Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) |
| |
| Authors: | V. Lehtovirta, M. Naslund, K. Norrman. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4771 |
|
This document defines an integrity transform for Secure Real-timeTransport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. |
|
| |
| RFC 4772 | Security Implications of Using the Data Encryption Standard (DES) |
| |
| Authors: | S. Kelly. |
| Date: | December 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4772 |
|
The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by theAdvanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. |
|
| |
| RFC 4773 | Administration of the IANA Special Purpose IPv6 Address Block |
| |
|
|
This is a direction to IANA concerning the management of the IANASpecial Purpose IPv6 address assignment registry. |
|
| |
| RFC 4774 | Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field |
| |
|
|
There have been a number of proposals for alternate semantics for theExplicit Congestion Notification (ECN) field in the IP header[RFC3168]. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. |
|
| |
| RFC 4775 | Procedures for Protocol Extensions and Variations |
| |
| Authors: | S. Bradner, B. Carpenter, Ed., T. Narten. |
| Date: | December 2006 |
| Formats: | txt html json |
| Also: | BCP 0125 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4775 |
|
This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.
This document is directed principally at other Standards DevelopmentOrganizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. |
|
| |
| RFC 4776 | 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 4777 | IBM's iSeries Telnet Enhancements |
| |
| Authors: | T. Murphy Jr., P. Rieth, J. Stevens. |
| Date: | November 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2877 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4777 |
|
This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allowsTelnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.
These support functions are implemented primarily using the TelnetEnvironment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. |
|
| |
| RFC 4778 | Operational Security Current Practices in Internet Service Provider Environments |
| |
| Authors: | M. Kaeo. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4778 |
|
This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. |
|
| |
| RFC 4779 | ISP IPv6 Deployment Scenarios in Broadband Access Networks |
| |
| Authors: | S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4779 |
|
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP)Broadband (BB) networks in coexistence with deployed IPv4 services.Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. |
|
| |
| RFC 4780 | Management Information Base for the Session Initiation Protocol (SIP) |
| |
| Authors: | K. Lingle, J-F. Mule, J. Maeng, D. Walker. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4780 |
|
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 a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include UserAgents, and Proxy, Redirect and Registrar servers. |
|
| |
| RFC 4781 | Graceful Restart Mechanism for BGP with MPLS |
| |
| Authors: | Y. Rekhter, R. Aggarwal. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4781 |
|
A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism forBGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's(LSR's) control plane restart, and specifically by the restart of itsBGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.
The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network LayerReachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried inBGP (e.g., IPv4, IPv6, etc.). |
|
| |
| RFC 4782 | Quick-Start for TCP and IP |
| |
| Authors: | S. Floyd, M. Allman, A. Jain, P. Sarolahti. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4782 |
|
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers,IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where theQuick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. |
|
| |
| RFC 4783 | GMPLS - Communication of Alarm Information |
| |
|
|
This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.
This document updates RFC 3473, "Generalized Multi-Protocol LabelSwitching (GMPLS) Signaling Resource ReserVation Protocol-TrafficEngineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. |
|
| |
| RFC 4784 | Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks |
| |
| Authors: | C. Carroll, F. Quick. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4784 |
|
The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update(DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUSAuthentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as aMobile IP Foreign Agent (FA). cdma2000(R) is a registered trademark of the TelecommunicationsIndustry Association (TIA). |
|
| |
| RFC 4785 | Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) |
| |
| Authors: | U. Blumenthal, P. Goel. |
| Date: | January 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4785 |
|
This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport LayerSecurity (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. |
|
| |
| RFC 4786 | Operation of Anycast Services |
| |
| Authors: | J. Abley, K. Lindqvist. |
| Date: | December 2006 |
| Formats: | txt json html |
| Also: | BCP 0126 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4786 |
|
As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. |
|
| |
| RFC 4787 | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP |
| |
|
|
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handlingUnicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. |
|
| |
| RFC 4788 | Enhancements to RTP Payload Formats for EVRC Family Codecs |
| |
|
|
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. |
|
| |
| RFC 4789 | Simple Network Management Protocol (SNMP) over IEEE 802 Networks |
| |
|
|
This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.
This document obsoletes RFC 1089. |
|
| |
| RFC 4790 | Internet Application Protocol Collation Registry |
| |
| Authors: | C. Newman, M. Duerst, A. Gulbrandsen. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4790 |
|
Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the InternetEngineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. |
|
| |
| RFC 4791 | Calendaring Extensions to WebDAV (CalDAV) |
| |
|
|
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. |
|
| |
| RFC 4792 | Encoding Instructions for the Generic String Encoding Rules (GSER) |
| |
|
|
Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules(GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSERChoiceOfStrings type. |
|
| |
| RFC 4793 | The EAP Protected One-Time Password Protocol (EAP-POTP) |
| |
| Authors: | M. Nystroem. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4793 |
|
This document describes a general Extensible Authentication Protocol(EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet KeyExchange Protocol Version 2 (IKEv2). |
|
| |
| RFC 4794 | RFC 1264 Is Obsolete |
| |
|
|
RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. |
|
| |
| RFC 4795 | Link-local Multicast Name Resolution (LLMNR) |
| |
| Authors: | B. Aboba, D. Thaler, L. Esibov. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4795 |
|
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and futureDNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute forDNS. |
|
| |
| RFC 4796 | The Session Description Protocol (SDP) Content Attribute |
| |
| Authors: | J. Hautakorpi, G. Camarillo. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4796 |
|
This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently(e.g., show it on a big or small screen) based on its content. |
|
| |
| RFC 4797 | Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks |
| |
| Authors: | Y. Rekhter, R. Bonica, E. Rosen. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4797 |
|
This document describes an implementation strategy for BGP/MPLS IPVirtual Private Networks (VPNs) in which the outermost MPLS label(i.e., the tunnel label) is replaced with either an IP header or anIP header with Generic Routing Encapsulation (GRE).
The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. |
|
| |
| RFC 4798 | Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) |
| |
| Authors: | J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4798 |
|
This document explains how to interconnect IPv6 islands over aMultiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are DualStack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using theMultiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the6PE router so that dynamically established IPv4-signaled MPLS LabelSwitched Paths (LSPs) can be used without explicit tunnel configuration. |
|
