Guidelines for Writing an IANA Considerations Section in RFCs
01 Oct 1998-Vol. 2434, pp 1-11
TL;DR: Many protocols make use of identifiers consisting of constants and other well-known values that must be administered by a central authority to insure that such quantities have consistent values and interpretations in different implementations.
Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
Citations
More filters
01 Jul 2003
TL;DR: A logging instrument contains a pulsed neutron source and a pair of radiation detectors spaced along the length of the instrument to provide an indication of formation porosity which is substantially independent of the formation salinity.
Abstract: The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.
11,490 citations
Proceedings Article•
01 Jan 1997
TL;DR: The Hypertext Transfer Protocol is an application-level protocol for distributed, collaborative, hypermedia information systems, which can be used for many tasks beyond its use for hypertext through extension of its request methods, error codes and headers.
Abstract: The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
3,881 citations
01 Feb 2007
TL;DR: The Dynamic Source Routing protocol is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes, designed to work well even with very high rates of mobility.
Abstract: 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 mechanisms of "Route Discovery" and "Route
Maintenance", which work together to allow nodes to discover and
maintain source routes to arbitrary destinations in the ad hoc
network. The use of source routing allows packet routing to be
trivially loop-free, avoids the need for up-to-date routing
information in the intermediate nodes through which packets are
forwarded, and allows nodes forwarding or overhearing packets to cache
the routing information in them for their own future use. All aspects
of the protocol operate entirely on-demand, allowing the routing
packet overhead of DSR to scale automatically to only that needed to
react to changes in the routes currently in use. This document
specifies the operation of the DSR protocol for routing unicast IP
packets in multi-hop wireless ad hoc networks.
1,649 citations
01 Dec 2001
TL;DR: In this paper, the use of RSVP (Resource Reservation Protocol) to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching) is described.
Abstract: This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching) Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702
1,479 citations
01 Jan 1997
TL;DR: This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.
Abstract: This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.
1,289 citations
References
More filters
01 Mar 1997
TL;DR: This document defines these words as they should be interpreted in IETF documents as well as providing guidelines for authors to incorporate this phrase near the beginning of their document.
Abstract: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
3,501 citations
01 Aug 1995
TL;DR: This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer, and obsoletes RFC 2401 (November 1998).
Abstract: This document describes an updated version of the "Security
Architecture for IP", which is designed to provide security services
for traffic at the IP layer. This document obsoletes RFC 2401
(November 1998). [STANDARDS-TRACK]
3,455 citations
[...]
01 Sep 1981
TL;DR: Along with TCP, IP represents the heart of the Internet protocols and has two primary responsibilities: providing connectionless, best-effort delivery of datagrams through an internetwork; and providing fragmentation and reassembly of data links to support data links with different maximum transmission unit (MTU) sizes.
Abstract: IP is a network layer (Layer 3) protocol that contains addressing information and some control information that enables packets to be routed. IP is documented in RFC 791 and is the primary network layer protocol in the Internet protocol suite. Along with TCP, IP represents the heart of the Internet protocols. IP has two primary responsibilities: providing connectionless, best-effort delivery of datagrams through an internetwork; and providing fragmentation and reassembly of datagrams to support data links with different maximum transmission unit (MTU) sizes.
1,967 citations
01 Oct 1996
TL;DR: This memo documents the process used by the Internet community for the standardization of protocols and procedures, the requirements for moving a document between stages and the types of documents used during this process.
Abstract: This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
342 citations
01 Feb 1998
TL;DR: This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...).
Abstract: Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
335 citations