| |
|
| |
| | Additional ECC Groups For IKE and IKEv2 |
| |
|
This document describes additional elliptic curve groups for use in IKE (as defined in RFC 2409) and IKEv2 (as defined in RFC 3406). These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, and in addition, many of them provide higher strength than the previousley defined Oakley groups. |
| | Cisco Systems' Simple Certificate Enrollment Protocol |
| |
|
This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. |
| | A Protocol for Remotely Managing Sieve Scripts |
| |
|
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. |
| | LDAP Administrators Address Attribute |
| |
|
Organizations with multiple or outsourced directory servers need the ability for administrators to determine who is responsible for a particular directory server. This document defines an attribute with contact information for a directory server's responsible party, conceptually similar to the 'sysContact' object of SNMP, which can be retrieved from the directory server using the Lightweight Directory Access Protocol. |
| | Secure Internet Live Conferencing (SILC),Protocol Specification |
| |
|
This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC provides advanced and feature rich conferencing services with security as main design principal. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other specifications relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. |
| | SILC Packet Protocol |
| |
|
This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. |
| | SILC Key Exchange and Authentication Protocols |
| |
|
This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol supports passphrase (pre-shared secret) authentication and public key (and certificate) authentication based on digital signatures. |
| | Multicast in MPLS/BGP IP VPNs |
| |
|
This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. |
| | The ARK Persistent Identifier Scheme |
| |
| | draft-kunze-ark-15.txt |
| | Date: |
22/05/2008 |
| | Authors: |
John Kunze, Richard Rodgers |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending a single question mark (`?'), returns a brief metadata record that is both human- and machine- readable. When the ARK is inflected by appending dual question marks (`??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. |
| | SILC Commands |
| |
|
This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. |
| | Compressed Data within an Internet EDI Message |
| |
|
This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. |
| | IPv4 Address Conflict Detection |
| |
|
When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host or administrator may respond to rectify the problem. |
| | URI Scheme for GSM Short Message Service |
| |
|
This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. |
| | Media Gateway Control Protocol Fax Package |
| |
|
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. |
| | Analysis of Inter-Domain Routing Requirements and History |
| |
|
This document analyses the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical concensus of the research group at the date of publication. [Note to RFC Editor: Please replace the reference in the abstract with a non-reference quoting the RFC number of the companion document when it is allocated, i.e., '(RFC xxxx)' and remove this note.] |
| | IMAP METADATA Extension |
| |
|
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. |
| | Web Distributed Authoring and Versioning (WebDAV) SEARCH |
| |
|
This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. |
| | An IPv4 Flowlabel Option |
| |
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. |
| | SILC Message Flag Payloads |
| |
|
This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads. |
| | User Online Presence and Information Attributes |
| |
|
This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. |
| | Dynamic Hostname Exchange Mechanism for OSPF |
| |
|
Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This document defines a new OSPF Router Information (RI) TLV which allows the OSPF routers to flood their hostname-to-Router ID mapping information across the OSPF network. This mechanism is applicable to both OSPFv2 and OSPFv3. |
| | Using PPP-over-Ethernet (PPPoE) in Wireless LANs |
| |
|
This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. |
| | EAP-Support in Smartcard |
| |
|
This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). |
| | Guidelines for Mandating the Use of IPsec Version 2 |
| |
|
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. |
| | Split Multi-link Trunking (SMLT) |
| |
|
This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC3768]. SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3. |
| | Reliable Server Pooling Applicability for IP Flow Information Exchange |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. |
| | Early Retransmit for TCP and SCTP |
| |
|
This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. |
| | Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) |
| |
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. |
| | Lumas - Language for Universal Message Abstraction and Specification |
| |
|
A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. |
| | Memorandum for multi-domain Public Key Infrastructure Interoperability |
| |
|
The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI. |
| | A Set of Possible Requirements for a Future Routing Architecture |
| |
|
The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. |
| | Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment |
| |
|
This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. |
| | Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling |
| |
|
This memo specifies a throttle mechanism for limiting the rate of Session Initiation Protocol (SIP) event notifications. This mechanism can be applied in subscriptions to all SIP event packages, but the mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS). |
| | PATCH Method for HTTP |
| |
|
Several applications extending HTTP require a feature to do partial resource modification. Existing HTTP functionality only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. |
| | SixXS Heartbeat Protocol |
| |
|
This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. |
| | Mixmaster Protocol Version 2 |
| |
|
Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis. |
| | IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) |
| |
|
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. |
| | A QoS Model for Signaling IntServ Controlled-Load Service with NSIS |
| |
|
This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used. |
| | Terminology for Benchmarking LDP Data Plane Convergence |
| |
|
This document defines new terms for benchmarking of LDP convergence. These terms are to be used in future methodology documents for benchmarking LDP Convergence. Existing BMWG terminology documents such as IGP Convergence Benchmarking [3] provide useful terms for LDP Convergence benchmarking. These terms are discussed in this document. Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and [2] is also discussed. |
| | User Session Tracking in RADIUS |
| |
|
This document defines a set of new messages and attributes designed to allow RADIUS servers to cleanly track user sessions. |
| | DNS Blacklists and Whitelists |
| |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. IRTF Notice This document is a product of the Anti-Spam Research Group (ASRG). Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org. This document is not an IETF Internet Standard. It represents the consensus of the Anti-Spam Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF in the future. |
| | Guidelines for Management of DNSBLs for Email |
| |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists ("DNSBLs") of IP addresses or domain names intended to help guide email filtering. This memo discusses guidelines for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. |
| | RADIUS Error Messages |
| |
|
This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients. |
| | Light Weight Access Point Protocol |
| |
|
In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. |
| | Licklider Transmission Protocol - Specification |
| |
| | draft-irtf-dtnrg-ltp-10.txt |
| | Date: |
25/06/2008 |
| | Authors: |
Manikantan Ramadas, Scott Burleigh, Stephen Farrell, Intellectual Property |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful, and has no negotiation or handshakes. In an Interplanetary Internet setting deploying the Bundle protocol that is being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable "convergence layer" protocol operating in pairwise fashion between adjacent Interplanetary Internet nodes that are in direct RF communication. In that operational scenario, and potentially in some other deployments of the Bundle Protocol, LTP runs directly over a data- link layer protocol; when this is the case, forward error correction coding and/or checksum mechanisms in the underlying data-link layer protocol must assure the integrity of the data passed between the communicating entities. Since no mechanisms for flow control or congestion control are included in the design of LTP, this protocol is not intended or appropriate for ubiquitous deployment in the global Internet. When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol, (nominally a link- layer protocol), that meets the requirements specified in section 5. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
| | Internet Mail Architecture |
| |
|
Over its thirty-five year history Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. The first standardized architecture for networked email specified little more than a simple split between the user world and the transmission world. Core aspects of the service, such as the styles of mailbox address and basic message format, have remained remarkably constant. However today's Internet Mail is distinguished by many independent operators, many different components for providing service to users and many others for performing message transfer. Public discussion of the service often lacks common terminology and a common frame of reference for these components and their activities. Having a common reference model and terminology facilitates discussion about problems with the service, changes in policy, or enhancement to the service's functionality. This document offers an enhanced Internet Mail architecture that targets description of the existing service, in order to facilitate clearer and more efficient technical, operations and policy discussions about email. |
| | Population Count Extensions to PIM |
| |
|
This specification defines a method for providing multicast distribution-tree accounting data for billing and debugging. Simple extensions to the PIM protocol allow a rough approximation of tree- based data in a scalable fashion. |
| | IP Fast Reroute using tunnels |
| |
|
This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. |
| | DISCOVER: Supporting Multicast DNS Queries |
| |
|
This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. |
| | The case against Hop-by-Hop options |
| |
|
The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks. |
| | Session Key Transport in RADIUS |
| |
|
This document describes an extension to the RADIUS protocol designed to support requests for, and delivery of, session key material between RADIUS clients and servers. The messages described in this document may be used for a wide variety of keying applications. |
| | RADIUS Attributes for the Delivery of Keying Material |
| |
|
This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. |
| | Extending the Space Available for TCP Options |
| |
|
This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. |
| | TLS Express |
| |
|
This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. |
| | Securing Neighbour Discovery Proxy Problem Statement |
| |
|
Neighbour Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Neighbour Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for neighbour discovery messages. Neighbour Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery. |
| | Group Co-operative Route Filtering capability for BGP-4 |
| |
|
Currently BGP-4 is capable of carrying multiple (Outbound Route Filters) ORFs entries for a given "AFI/SAFI". Each ORF provides a filter that a route whose NLRI matches AFI/SAFI, must pass through to be transmitted in the BGP Update message. Efficient processing of ORF filters may require ordering of individual ORFs in certain sequence and grouping of ORFs that should be applied together. The grouping functionality also provides the support for logical OR operation between the grouped ORFs. This group ORF provides an ORF type that specifies that ordering and grouping. The route set that passes set of ORFs running in a "Group ORF" will pass the same ORFs sent in normal ORFs. |
| | SDP Descriptors for FLUTE |
| |
|
This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. |
| | Scope Modifiers in Intellectual Property Declarations |
| |
|
The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet. |
| | Using XML Schema to define NETCONF Content |
| |
|
This memo defines a framework for defining content for NETCONF using a meta-model and XML Schema. The approach is to build on existing well-deployed technology and overlap management specific semantics to ensure high-quality interoperable definition of NETCONF content. |
| | The IPvLX Architecture |
| |
|
The IETF has embraced IPv6 as the next-generation Internet protocol, but global IPv4 deployment continues in private addressing domains behind Network Address Translators (NATs). This document envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). This document proposes an architectural framework for IPv6/IPv4 coexistence called: "IPvLX (IP with virtual Link Extension)". |
| | Atomsub: Transporting Atom Notifications over the Publish-Subscribe Extension to the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality. |
| | Message Header Field for Indicating Message Authentication Status |
| |
|
This memo defines a new message header field for use with electronic mail messages to indicate the results of message authentication efforts. Mail user agents (MUAs) may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
| | Network-Layer Signaling: Transport Layer |
| |
|
The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ. Network Layer Signaling uses the RSVP on-path communication model to carry requests to middleboxes and other network devices. It is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol. |
| | Interaction between SIP and HIP |
| |
|
This document investigates the interworking between the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and the benefits that may arise from their combined operation. The aspect of exchanging Host Identities (or Host Identity Tags) in SIP/SDP for later usage with the Host Identity Protocol Protocol (HIP) is described in more detail as an example of this interworking. |
| | Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs |
| |
|
This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools |
| | Licklider Transmission Protocol - Motivation |
| |
|
This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does Atomatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
| | Licklider Transmission Protocol - Security Extensions |
| |
|
The Licklider Transmission Protocol (LTP), is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
| | The "OpenPGP" mail and news header field |
| |
|
This document describes the "OpenPGP" mail and news header field. The field provide information about the sender's OpenPGP key. See for more information. |
| | Care-of Address Test for MIPv6 using a State Cookie |
| |
|
This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre- established IPsec security associations. |
| | Certificate Exchange Messaging for EDIINT |
| |
|
The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). |
| | Circuit Cross-Connect |
| |
|
Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. |
| | Transmitting Confidential Data in RADIUS |
| |
|
This document defines a set of RADIUS Attributes designed to allow the secure transmission of sensitive or confidential data between RADIUS clients and servers and the strong authentication of any RADIUS message. |
| | Dynamic AS Re-Association At Confederation Edge |
| |
|
This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS. |
| | Session Initiation Protocol (SIP) Session Mobility |
| |
|
Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document. |
| | The 'mailto' URI Scheme |
| |
|
This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). |
| | EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) |
| |
|
EAP-TTLS is an EAP method that provides additional functionality beyond what is available in EAP-TLS [RFC5216]. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication mechanisms. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. This document describes EAP-TTLSv0; that is, the original version 0 of the EAP-TTLS protocol, which has been widely deployed. |
| | BGP Point to Multipoint LSP |
| |
|
This document describes motivations and use cases to P2MP extension of BGP. This extension will allow to make both Inter-AS and Intra-AS P2MP LSP that fit to some use cases then also clarify required features. |
| | P3P Policy Attributes for LDAP |
| |
|
This document defines attributes for use in the Lightweight Directory Access Protocol (LDAP) which contain URIs for privacy policy documents. These documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries). |
| | Wireless LAN Control Protocol (WiCoP) |
| |
|
The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). |
| | Multiple Attachments for EDI-INT |
| |
|
The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. |
| | Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004 |
| |
|
In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly. |
| | IANA Considerations for XCAST (Explicit Multi-Unicast) |
| |
|
