|
Internet Drafts - IDs for Aug/2008
Index - Month Index of IDs
All IDs - sorted by date)
31/08/2008
| |
|
| |
| | Security Assessment of the Internet Protocol version 4 |
| |
|
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). |
| | Recommendations for filtering ICMP messages |
| |
|
This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. |
| | Simple Authentication and Security Layer (SASL) |
| |
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 4422 [[when approved]]. |
| | Port Randomization |
| |
|
Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five- tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the random selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods, the described port number randomization algorithms provide improved security/obfuscation with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP. |
30/08/2008
| |
|
| |
| | Web Distributed Authoring and Versioning (WebDAV) SEARCH |
| |
|
This document specifies a set of methods, headers and properties 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.Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) DASL mailing list at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WebDAV DASL mailing list are archived at . An issues list and XML and HTML versions of this draft are available from . |
29/08/2008
| |
|
| |
| | Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks |
| |
| | draft-ietf-ccamp-rwa-info-00.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
| | Formats: |
txt |
|
This document provides an information model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of information described in this model is to facilitate constrained lightpath computation in WSONs. In particular in cases where there are no or a limited number of wavelength converters available in the WSON. This model currently does not include optical impairments. |
| | RTP Payload Format for 1-D Interleaved Parity FEC |
| |
|
This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is compatible with and used as a part of the DVB Application-layer FEC Specification. |
| | DVB Application-Layer Hybrid FEC Protection |
| |
|
This document describes the Application-layer Forward Error Correction (FEC) protocol that was developed by the Digital Video Broadcasting (DVB) consortium for the protection of media streams over IP networks. The DVB AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB AL-FEC offers a good protection against both bursty and random packet losses at a cost of decent complexity. The 1-D interleaved parity code and Raptor code have already been specified in separate documents and the current document normatively references these specifications. |
| | HTTP/1.1,part 1: URIs,Connections,and Message Parsing |
| |
| | draft-ietf-httpbis-p1-messaging-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. |
| | HTTP/1.1,part 2: Message Semantics |
| |
| | draft-ietf-httpbis-p2-semantics-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields. |
| | HTTP/1.1,part 3: Message Payload and Content Negotiation |
| |
| | draft-ietf-httpbis-p3-payload-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
xml txt |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. |
| | HTTP/1.1,part 4: Conditional Requests |
| |
| | draft-ietf-httpbis-p4-conditional-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
xml txt |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. |
| | HTTP/1.1,part 5: Range Requests and Partial Responses |
| |
| | draft-ietf-httpbis-p5-range-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. |
| | HTTP/1.1,part 6: Caching |
| |
| | draft-ietf-httpbis-p6-cache-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. |
| | HTTP/1.1,part 7: Authentication |
| |
| | draft-ietf-httpbis-p7-auth-04.txt |
| | Date: |
29/08/2008 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. |
| | Initial Hypertext Transfer Protocol (HTTP) Method Registrations |
| |
|
This document registers those Hypertext Transfer ProtocolHypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. |
| | Dynamic Prefix Allocation for NEMOv4 |
| |
|
The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. |
| | YANG - A data modeling language for NETCONF |
| |
|
YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. |
| | Transmitting Confidential Data in RADIUS |
| |
|
This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes, are designed to allow the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers. |
| | Extensible Supply-chain Discovery Service Concepts |
| |
|
This document is intended to seed discussion about the Extensible Supply-chain Discovery Service (ESDS), an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. Specified initially as a web service interface, the protocol defines event tracking and tracing operations as well as core object management operations. This document obsoletes "Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-03". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). |
| | Extensible Supply-chain Discovery Service Commands |
| |
|
The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document describes the details of the command interface of the ESDS. A full outline of all primary and support commands is included in this document along with examples. Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). |
| | Extensible Supply-chain Discovery Service Schema |
| |
|
The Extensible Supply-chain Discovery Service (ESDS) is an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. This document outlines the schema of the ESDS application layer protocol. This is the formal syntax of the web service interface specification in Web Service Description Language (WSDL) and XML Schema (XSD). Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). |
| | Streamlined FTP Command Extensions |
| |
|
This document specifies FTP commands to download thumbnails of remote images, remove entire directory trees, request the amount of storage space available to the user, request the size of a remote directory and its contents, and to specify an FTP host. The commands are designed to reduce the number of server / client exchanges, provide information that was not previously available, and to reduce bandwidth requirements for some higher level operations. |
| | New Tunnel-Type Values |
| |
|
This document defines a set of values for the Tunnel-Type RADIUS Attribute. |
28/08/2008
| |
|
| |
| | Binding Revocation for IPv6 Mobility |
| |
|
This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. |
| | Session Initiation Protocol Service Example -- Music on Hold |
| |
|
The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, but is simpler than the methods previously documented. |
| | Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) |
| |
|
The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations and other networked equipment. As time synchronization is more and more a mission critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to setup a monitoring system that is platform- and vendor-independant. This Internet draft provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP Version 4 standardization effort. |
| | Authentication and Confidentiality in PIM-SM Link-local Messages |
| |
|
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified. |
| | Early Retransmit for TCP and SCTP |
| |
| | draft-ietf-tcpm-early-rexmt-00.txt |
| | Date: |
28/08/2008 |
| | Authors: |
Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Ethan Blanton, Per Hurtig |
| | Working Group: |
TCP Maintenance and Minor Extensions (tcpm) |
| | Formats: |
txt |
|
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. |
27/08/2008
| |
|
| |
| | Transport Subsystem for the Simple Network Management Protocol (SNMP) |
| |
| | draft-ietf-isms-tmsm-13.txt |
| | Date: |
27/08/2008 |
| | Authors: |
David Harrington, Juergen Schoenwaelder |
| | Working Group: |
Integrated Security Model for SNMP (isms) |
| | Formats: |
txt |
|
This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. |
| | Multiple Care-of Addresses Registration |
| |
|
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. |
| | 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. |
| | Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP |
| |
|
Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow a transport layer data receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory because the data receiver is permitted to renege; that is, later discard a DATA chunk which previously has been SACKed. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. This document specifies Non-Renegable Selective Acknowledgements (NR- SACKs), an extension to SCTP's acknowledgment mechanism. NR-SACKs enable a data receiver to explicitly acknowledge out-of-order DATA chunks that have been delivered to the receiving application. (Recall that, in SCTP, out-of-order data sometimes can be delivered.) NR-SACKs also enable a data receiver to indicate any out-of-order DATA chunks on which the receiver guarantees never to renege. As opposed to SACKed DATA chunks, a sender can consider NR-SACKed DATA chunks as never requiring retransmission, thus freeing space in the data sender's retransmission queue sooner. |
| | Media Format Choices for RFCs |
| |
|
Documents in the RFC series normally use only plain-text ASCII characters and a fixed-width font. However, there is sometimes a need to supplement the ASCII text with graphics or picture images. The historic solution to this requirement, allowing secondary PDF and Postscript files, is seldom used because it is awkward for authors and publisher. This memo suggests a more convenient scheme for attaching authoritative diagrams, illustrations, or other graphics to RFCs. It further proposes conventions for additional input and display formats, to improve readability. This proposal is based on draft-rfc-image-files-00, by Braden and Klensin, and revises it as little as possible, while expanding the goals of the effort. |
| | Response Code for Indication of Terminated Dialog |
| |
|
This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP entity can use to indicate upstream that an early dialog has been terminated. The response code can be used by a SIP entity to indicate to the UAC that an early dialog has been terminated, before a final response is sent to the UAC. |
| | Netnews Architecture and Protocols |
| |
|
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.Internet Draft Comments Comments are solicited and should be addressed to the Usenet Format Working Group at ietf-usefor@imc.org. |
26/08/2008
| |
|
| |
| | Internet Key Exchange Protocol: IKEv2 |
| |
| | draft-ietf-ipsecme-ikev2bis-00.txt |
| | Date: |
26/08/2008 |
| | Authors: |
Charlie Kaufman, Paul Hoffman, Yoav Nir, Pasi Eronen |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
| | Formats: |
txt |
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. |
| | CUBIC for Fast Long-Distance Networks |
| |
|
CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. We expect this document to be eventually published as an experimental RFC. |
| | With-defaults capability for NETCONF |
| |
|
The NETCONF protocol defines ways to read configuration data from a NETCONF agent. Part of this data is not set by the NETCONF manager, but rather set to a default value by the NETCONF agent. In many situations the NETCONF manager has a priori knowledge about this data, so the NETCONF agent does not need to send it to the manager. In other situations the NETCONF manger will need this data as part of the NETCONF rpc reply messages. This document defines a capability- based extension to the NETCONF protocol that allows the NETCONF manager to control whether default values are part of NETCONF rpc reply messages. |
| | RADIUS Design Guidelines |
| |
|
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). |
| | Socket Application Program Interface (API) for Multihoming Shim |
| |
|
This document specifies a socket API for the multihoming shim layer. The API aims to enable interactions between the applications and the multihoming shim layer for advanced locator management and access to information about failure detection and path exploration. This document is based on an assumption that a multihomed host is equipped with a conceptual sublayer (here after "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. |
| | VoIP SIP Peering Use Cases |
| |
|
This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. In describing use cases, the intent is descriptive, not prescriptive. |
25/08/2008
| |
|
| |
| | Using IPsec between Mobile and Correspondent IPv6 Nodes |
| |
|
Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. |
| | Sharing Transaction Fraud Data |
| |
| | draft-mraihi-inch-thraud-07.txt |
| | Date: |
25/08/2008 |
| | Authors: |
Sharon Boeyen, Michael Grandcolas, Siddharth Bajaj, David M'Raihi |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. |
| | Common Architecture Label IPv6 Security Option (CALIPSO) |
| |
|
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. |
| | Resolver side mitigations |
| |
|
Describes a set of mitigations that stop the known Kaminsky variations, for which only resolver side deployment is necessary. |
| | EDNS EXPIRE OPTION |
| |
|
Provide a method for slave DNS servers to honour the SOA EXPIRE field as if they were always transferring from the master, even when using other slaves to perform indirect transfers and refresh queries. |
| | Expressing SNMP SMI Datatypes in XML Schema Definition Language |
| |
|
This memo (when approved as a standards-track RFC) defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. |
| | Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol |
| |
|
RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. |
23/08/2008
| |
|
| |
| | Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol |
| |
|
The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a range of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. |
22/08/2008
| |
|
| |
| | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. |
| | Multiple Interface Support with Proxy Mobile IPv6 |
| |
|
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It makes it appear to the mobile node that its IP address does not change as the mobile node moves across the Proxy Mobile IPv6 domain. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. This document describes and analyzes some of the scenarios associated with this. |
| | Ivip4 ETR Address Forwarding |
| |
|
ETR Address Forwarding (EAF) is a novel method by which an IPv4 Core- Edge Separation solution to the Internet's routing scaling problem can tunnel packets from an ITR to an ETR. EAF involves using 31 bits of the IPv4 header for new purposes: bit 48, the More Fragments flag, the Fragment Offset field and the Header Checksum field. Consequently, packets in this format need to be handled by routers with modified functionality. EAF is an alternative to encapsulation (map-encap) or address translation (Six/One Router) and has advantages including: simpler ITRs and ETRs, direct support for conventional RFC 1191 PMTUD, no encapsulation overhead and full compatibility with IPsec AH and Traceroute. |
| | IP and ARP over Wiegand |
| |
|
This document describes the transport of IP datagrams over the Security Industry Association standard [3] five-conductor cable called the Wiegand interface used for communication between card readers and control panels in physical access control systems. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications |
| |
|
The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the previously defined standard, and some questions about DHCPv4 server behaviour remain unclear. |
| | A Reliable Transport Mechanism for PIM |
| |
| | draft-ietf-pim-port-00.txt |
| | Date: |
22/08/2008 |
| | Authors: |
Dino Farinacci, IJsbrand Wijnands, Apoorva Karan, A Boers, Maria Napierala |
| | Working Group: |
Protocol Independent Multicast (pim) |
| | Formats: |
txt |
|
This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. |
| | TLS encryption for RADIUS over TCP (RadSec) |
| |
|
This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. |
| | A Framework for Session Initiation Protocol (SIP) Session Policies |
| |
|
Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. |
| | Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets |
| |
| | draft-ietf-tcpm-ecnsyn-06.txt |
| | Date: |
22/08/2008 |
| | Authors: |
Sally Floyd, Aleksandar Kuzmanovic, Amit Mondal, K. K. Ramakrishnan |
| | Working Group: |
TCP Maintenance and Minor Extensions (tcpm) |
| | Formats: |
txt |
|
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. This document updates RFC 3168. |
21/08/2008
| |
|
| |
| | 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. |
| | RTP Payload Format for MVC Video |
| |
|
This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format has wide applicability, such as 3D video streaming, free-viewpoint video, and 3DTV. |
| | Digital Signatures on Internet-Draft Documents |
| |
|
This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. |
| | Nest Route Optimization for NEMO (NERON) |
| |
|
IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support protocol that handles the mobility management of IPv6 based mobile networks. However the NEMO protocol has severe performance limitations and does not specify the route optimization method for mobile networks and does not take into account the operational and functional complexities involving nested mobile networks. In this draft we present NEst Route Optimization for NEMO (NERON) protocol, a light weight, efficient and scalable approach that aims at enabling nodes behind nested mobile networks to use optimized communication paths with zero tunneling overhead and minimum end-to- end delay, irrespective of the depth of the nest, with minimum but manageable changes to the base MIPv6 and IPv6 Neighbor Discovery protocols and without introducing any new network entities. |
| | Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6 |
| |
|
Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. |
20/08/2008
| |
|
| |
| | Media Control Channel Framework |
| |
|
This document describes a Framework and protocol for application deployment where the application programming logic and processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co- located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. |
| | MANET Autoconfiguration using Virtual Enterprise Traversal (VET) |
| |
|
Mobile Ad-hoc Networks (MANETs) connect routers on links with asymmetric reachability characteristics, and may also connect to other networks including the Internet. Routers in MANETs must have a way to automatically provision IP addresses/prefixes and other information. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of routers in MANETs. |
| | An XCON Client Conference Control Package for the Media Control Channel Framework |
| |
|
The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server control, thus optimizing the implementation for some entities participating in an XCON system. |
| | Home Agent assisted Route Optimization between Mobile IPv4 Networks |
| |
|
This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol. |
| | Call on hold for telephony applications of SIP protocol |
| |
|
Many RFCs and Internet Drafts describe call on hold methods adopted in SIP signaling protocol. The actual implementation may not always be ideal for telephony applications (reasons are explained below). This draft proposes a revision of call on hold method for SIP protocol. Giordano [page 1] Internet-Draft Call on hold for telephony applications of SIP protocol |
| | A Session Description Protocol (SDP) Control Package Attribute |
| |
|
This document defines a new Session Description Protocol (SDP) media- level attribute: "ctrl-package". The "ctrl-package" attribute conveys details of the SIP Control Framework extension packages that are supported by a client participating in an offer/answer exchange. |
| | Indicating Support for Basic Media Server Capabilities in the Session Initiation Protocol (SIP) |
| |
|
This specification defines a profile set of media feature tags that can be used with the Session Initiation Protocol (SIP). The media feature tags allow a Media Server to communicate a basic set of media server capabilities that are supported to its Application Server. |
| | Ivip Mapping Database Fast Push |
| |
|
Ivip (Internet Vastly Improved Plumbing) is a proposed map-encap system which is intended to provide a solution for the routing scaling problem - supporting growing numbers of end-user networks with multihoming, traffic engineering and portability, without further growth in the global BGP routing table. Ivip is also intended to provide other benefits, including a new form of IPv4 and IPv6 mobility and better utilization of IPv4 address space. To achieve these benefits, Ivip relies on a "fast mapping database push" system, which is required to securely and reliably deliver updates to the mapping database to hundreds of thousands - or potentially millions - of ITRs (Ingress Tunnel Routers) and Query Servers (QSes) all over the Net, ideally within a few seconds. This ID describes the requirements of such a system and how it could be implemented so as to cope with very large numbers of updates and ITR/QS sites. |
| | A New BGP Standards Action Community,LAST_RESORT |
| |
|
This Internet Draft describes a new Standards Action BGP community, LAST_RESORT. This community provides a simple and easily deployable solution to a certain class of BGP "wedgies". Initial deployment is expected to be achieved by voluntary use in the network operator community-at-large. Long-term adoption via software enforcement of the community, will improve global behavior, and simplify router configurations. The Standards Action range of communities (previously limited to the "well-known" communities) ensures that the expectation of (eventual) router support is reasonable. |
| | Neighbor Discovery Suppression |
| |
|
The 6LoWPAN IETF working group is developing protocols to allow IPv6 end-to-end communication with sensors networks. Low-power MAC protocols such as IEEE 802.15.4 impose a slightly reduced frame size. To enable IPv6 communication, 6LoWPAN proposes to use fragmentation and header compression techniques. This document proposes an extension to the 6LoWPAN proposal and defines a class of sensors that can be joined at the network level while ignoring their own global IPv6 address. This architecture centralizes the address management on the sensor network gateway (the PAN Coordinator) and allows the suppression of the Neighbor Discovery Protocol. Consequently, the insertion of sensors in such a network is faster and the traffic within the network, largely composed of broadcast messages generated by Neighbor Discovery Protocol, is reduced. We investigate the impact of this architecture on star and mesh topologies. |
| | Rbridge Notes |
| |
|
This document provides additional informational material related to RBridges, which are devices that implement the TRILL protocol. It is a supplement to the RBridges base protocol specification and includes discussion of tradeoffs in some features and configurations of RBridges. In addition, it provides a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. |
19/08/2008
| |
|
| |
| | DHCPv6 option for network boot |
| |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes a new option for DHCPv6 to convey information, required for network booting, to the nodes. |
| | The IMAP NOTIFY Extension |
| |
| | draft-ietf-lemonade-imap-notify-07.txt |
| | Date: |
19/08/2008 |
| | Authors: |
Arnt Gulbrandsen, Alexey Melnikov, Curtis King |
| | Working Group: |
Enhancements to Internet email to Support Diverse Service Environments (lemonade) |
| | Formats: |
txt |
|
This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. [[Add Updates: RFC-CONTEXT to the headers]] |
| | IANA Considerations for RPC Net Identifiers and Universal Address Formats |
| |
|
This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. |
| | 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. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home basement networks) are mentioned in the following to exemplify its possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. |
| | IEEE 802.21 Basic Schema |
| |
|
This document describes the basic schema for IEEE 802.21 Media- Independent Information Service, an RDF (Resource Description Framework) schema defined in IEEE 802.21. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema. |
| | Ivip (Internet Vastly Improved Plumbing) Architecture |
| |
| |