This document describes various models for endpoint control of media policy for centralized conferencing services. The models include detailed mixer control, as in H.248, individual end-point negotiation, and participant roles, as in MSCML. This memo presents a proposal for an efficient and simple way of forming email addresses. The goal is to achieve easier, more productive communication between email users, in particular by aking addresses intuitive and thus easy to remember, or guess-enabled on material-world data about the correspondent, as well as independent from technical or organizational specifics of email services. IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to its existing IPv4 sites. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, 6rd requires a service provider to use one of its own IP prefixes rather than the fixed 6to4 prefix. A service provider has used this mechanism for its own "rapid deployment" of IPv6 (five weeks from first exposure to "opt-in" deployment for 1,500,000 residential sites). Proxy Mobile IPv6 (PMIPv6) is a network-based mobility protocol that enables mobility management for an IP host as it moves across different points of attachment within the mobility domain. An IP host whose mobility is being managed by the network is unaware of the access networks capability providing PMIPv6 mobility management on its behalf. This draft proposes mechanisms by which the host is informed of PMIPv6, as well as means to actively discover such capability in the network the host is attaching to. The ability of the host to discover or be aware of PMIPv6 support in the access network enables better decision making in terms of the network selection, attach procedure, choice of mobility management, as well as the service/session and even application configuration abilities. This document examines the role of the transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field to indicate that no checksum is present. The document describes issues and design principles that need to be considered and provides recommendations. This document describes a SIP-based method for network initiated partial session transfers that works together with terminal initiated partial session transfers. It uses the Mobile Node Control Mode for terminal initiated partial session transfers and it extends this method to support network initiated partial session transfers. This document describes LOWPAN_TCPHC, a scheme for compressing the header of Transmission Control Protocol (TCP) segments, in order to reduce the overhead on low-power and lossy networks. It also specifies the LOWPAN_TCPHC header fields for the transmission of TCP segments over IPv6 for Low-power Wireless Personal Area Networks (6LoWPAN). In many cases, the 20 bytes of the mandatory TCP header can be compressed into as little as 6 bytes. XCAST6 (Explicit Multiunicast on IPv6) is a new protocol defined in RFC 5058. In XCAST, the list of destinations is explicitly encoded within the data packets instead of using a multicast group address. Research is currently ongoing on two versions of XCAST6 and this document describes the design and implementation of a routing engine for the new version in which the use of hop-by-hop options header has been eliminated. This draft explains why there is a need for an XCAST6 routing engine, highlights the requirements for its implementation, the design process and how to eventually implement the routing engine to allow for deployment of XCAST6 protocol. This document defines the Origin attribute for cookies, which lets servers harmonize the security policy of their cookies with the widely used same-origin policy. Origin cookies provide both confidentiality and integrity, unlike the Secure attribute, which provides only confidentiality.Editorial Note (To be removed by RFC Editor) If you have suggestions for improving this document, please send email to <mailto:http-state@ietf.org>. Further Working Group information is available from <https://tools.ietf.org/wg/httpstate/>. This document defines the HTTP Cookie and Set-Cookie headers. These headers can be used by HTTP servers to store state on HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. The cookie protocol has many historical infelicities and should be avoided for new applications of HTTP. NOTE: If you have suggestions for improving the draft, please send email to http-state@ietf.org. Suggestions with test cases are especially appreciated. Many web servers supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content-Type header fields when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. Please send feedback on this draft to apps-discuss@ietf.org. This document defines the concept of an "origin", which represents a web principal. Typically, user agents isolate content retrieved from different origins to prevent a malicious web site operator from interfering with the operation of benign web sites. In particular, this document defines how to compute an origin from a URI, how to serialize an origin to a string, and an HTTP header, named "Origin", for indicating which origin caused the user agent to issue a particular HTTP request. The security model of the web platform has evolved over time to meet the needs of new applications and to correct earlier mistakes. Although web security has evolved largely organically, the security model has converged towards a handful of key concepts. This document presents those concepts and provides advice to designers of new pieces of the web platform. The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Please send feedback to the hybi@ietf.org mailing list. This document contains a precise specification of how browsers process URLs. The behavior specified in this document might or might not match any particular browser, but browsers might be well-served by adopting the behavior defined herein.Editorial Note (To be removed by RFC Editor) If you have suggestions for improving this document, please send email to <mailto:public-iri@w3.org>. Further Working Group information is available from <https://tools.ietf.org/wg/iri/>. The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Please send feedback to the hybi@ietf.org mailing list. This memo documents the implementation of the HOST_ID TCP Options. It also discusses the preliminary results of the tests that have been conducted to assess the technical feasibility of the approach as well as its scalability. Several HOST_ID TCP options have been implemented and tested. The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies a protocol for route optimization in networks, which support network-based mobility management. The specified protocol focuses on efficient set up and maintenance of a route optimized path between two mobile nodes and suits complex mobility scenarios as well as networks with multiple mobility anchors. This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Near-Field Communication Forum (NFC Forum). The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. The virtual broadband access server (VBAS) protocol looks BAS and IP-DSLAM as a whole and provides an applicable method for communicating between BAS and IP-DSLAM. This document describes a communication process, which is added in the existing access control modes. It also describes how to encapsulate VBAS packets over Ethernet. The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering,, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs and provides for compatibility with MPLS. The control plane for Pseudowires (PWs) is also covered by this document. Management plane functions such as manual configuration and the initiation of LSP setup are out of scope of this document. The unused fields in TCP/IP can be used to establish malicious communication channel[1][2][3]. This draft presents the fieldsin TCP/IP and ICMP messages and the values which must be enforced before the packets are streamed to the network so as to prevent the malicious communication channel. EAP is used to establish secure communication channel in IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, EAP-SIM uses radius protocol for communication bewteen radius server and the client. These protocols are used in both Wireless network authentication and in IKEV2 authentication to establish VPN tunnel. +----------+ +----------+ +----------+ | | EAPOL | EAP | RADIUS | | | EAP |<------>| Server |<------>| RADIUS | | Client | EAPOW | | (EAP) | Server | | | | | | | +----------+ +----------+ +----------+ This draft presents the security protocol which can be used to establish the secure communication channel between the radius server and pass through server. Pass through server is access point in the case of wireless communication and it is gateway in case of IKEV2 authnetication. In a public WLAN hotspot, we need to have an easy and secure way to authenticate users. We have to find also mobility solutions, given by providers, to perform well the roaming. A roaming mobile terminal MT may be within radio range of more than one access point AP. Therefore, we need to make an intelligent network selection decision after receiving some roaming information. Currently, the information is typically provisioned on the MTs as static roaming tables. But, this approach is not scalable when there is a large number of access points. In this draft, we propose our solution called OSFR, Optimized Network Selection for Fast Roaming to improve association speed and scalability. This draft introduces the Certified PN Formation Protocol (CPFP) based on the personal public key infrastructure (personal PKI) concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques by using ECDH, ECDSA and STS protocols and provides feasible solutions for key revocation and transitive imprinting. Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the history of that cooperation, and the policies and procedures that have developed in order to coordinate between the two organizations. This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as providing clarifications on the usage of the EAP-Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This document defines a resource reservation protocol Hierarchical Proxy Mobile Resource Reservation Protocol (HPMRSVP). This protocol is based on the hierarchical architecture HMIPv6 and used a modified version of FHMIPv6 to handle the handover. During a session, the resource reservation between two mobile nodes is limited to the access network. Furthermore, when a handover occurs, resources are uniquely reserved to the target access point before the handover is completed. The proposed protocol allows to reduce delays and packet loss. In addition, management of refresh messages is moved to the access router, which holds the refresh reservation state for the duration of the session on behalf of the mobile unit. The access network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. Session Initiation Protocol (SIP) is passed on point-to-point protocol. This document describes a Multipoint Session Initiation Protocol. This protocol is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. The protocol is based on distributed network entities architecture, and the use of the server is mandatory. The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This document describes a two rate three color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore this marker doesn’t impose peak rate shaping requirements on customer edge (CE) devices. This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a common set of TLVs that is carried on LSP Ping. Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. This document describes an extension to Mobile IPv4 Registration Revocation (as described in RFC 3543) for a home or foreign agent to revoke mobile IP services for multiple bindings or visitors with a single registration revocation exchange. OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. This document defines a DHCP option that contains Radio specific Parameters for Mobile Access Points, Like Transmit Power, Country code, reserved RF channels. This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure. These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. The PKIX (Public-Key Infrastructure (X.509)) Working Group of the IETF (The Internet Engineering Task Force) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the CRMF (Certificate Request Message Format) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP (PKIX Certificate Management Protocol) and CMC (Certificate Management Messages over CMS). This document describes the motivation for Flow State Aware signalling and proposes a method of enabling Flow State Aware signalling packets to be identified. This document describes the work in progress on Flow State Aware standards activity in the ITU and proposes a new type of control packet to be identified that can alert downstream or upstream nodes on data related to an individual flow. The Network File System, version 4 (NFSv4) uses a representation of identity that allows the use of users and groups from multiple, distinct administrative domains, and NFSv4 allows the use of security mechanisms that authenticate principals from multiple, distinct administrative domains. This document describes methods by which NFSv4 clients and servers can handle principals, users, groups from multiple administrative domains. This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a user on a client and a server, authenticating both the user and server with public key certificates [RFC3280], without the need for an external Public Key Infrastructure for certificate verification. The method leverages the existing Simple Public Key Mechanism Version 3 (SPKM-3) [RFC2847]. In addition to describing the use of SPKM-3 for mutual authentication, this memorandum updates RFC2847, reflecting implementation experience. This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a public-key based secure channel between a client and a server without the need for an external Public Key Infrastructure for certificate verification. The method leverages the existing Simple Public Key Mechanism (SPKM), and is specified as two separate GSS-API mechanisms, SPKM-3 and LIPKEY, with LIPKEY layered above SPKM-3. SPKM-3 describes a method for creation of the secure channel using mutual authentication where both a user and server authenticate with public-key certificates [RFC3280]. SPKM-3 also describes a method for creation of the secure channel where only the server authenticates with a public-key certificate, and the user is anonymous. LIPKEY then uses the SPKM-3 anonymous secure channel to authenticate a user with a password, completing the mutual authentication. This document describes some security risks of the Reliable Multicast Transport (RMT) Working Group set of building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further discussion and potential resolution of any significant security issues that may exist in the current set of RMT standards. In this paper we propose a new hierarchical method to enhance the current routing and forwarding paradigm for the Internet called Tunneled Inter-Domain Routing (TIDR). We will present the way in which TIDR permits to establish tunnels to the edge of the network, and how they will be used to forward traffic to stub networks. These tunnels will be explicitly signaled by using a new transitive BGP attribute called LOCATOR. This new routing and forwarding paradigm provides, among others, the following benefits: global routing table reduction, inter-domain routing infrastructure protection, improved multi-homing of edge networks, numerous forwarding decisions for a particular address prefix, it stops the AS number consumption, and it can be smoothly deployed. Several wireless ad-hoc routing protocols have been and are being developped for MANET. However, autoconfiguration of MANET networks is still an unsettled area, and several methods have been proposed to perform such a task. One of the mecanisms that may be required for address autoconfiguration, is the detection of address conflicts. This is specially true for one of scenarios for MANET autoconf, the This document specifies a general protocol for the detecting address conflicts in a MANET network, and hence addresses a subset of the requirements of a full MANET address autoconfiguration solution. It is specified as an independent protocol from the MANET routing protocol, and the address configuration method, and may be used with any of them. It aims at conceptual simplicity: essentially, a tree of the nodes is built, from which all the information from all the existing nodes is known. Conflicts are detected by the node at root of the tree, or as inconsistent information on the root of the tree. This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This document proposes a solution for Service Network discovery and selection that could be implemented within the existing EAP specification framework. The purpose of Service Network discovery and selection here is to help a WLAN client using EAP for authentication to decide whether or not to connect to a WLAN Access Network, and help it select the most appropriate Mediating Network as a next hop for routing AAA packets in roaming situations where the WLAN Access Network has agreements with more than one Mediating Network affiliated with the client’s Home Service Network. The proposed solution has 3 components: a delivery mechanism for conveying Access Network and Service Network Information to a WLAN client, a data model/syntax for structuring the information in a generic manner, and a method by which the WLAN client can indicate its selection to the WLAN Access Network. The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer - the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker. The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This document describes additional Remote Authentication Dial In User Service (RADIUS) [1] attributes for use of RADIUS AAA (Authentication, Authorization, Accounting) in both Wireless and wired networks. It contains an IPv4 address type control mechanism, mobile IPv4 home agent discovery mechanism, and a RADIUS capabilities discovery mechanism. This document describes bandwidth profile parameters and a protocol framework that enables an AAA server to specify the parameters that should be allocated by the access network for duration of an authorized user session. This document describes a new RADIUS attribute used by a home RADIUS to indicate Chargeable User Identity to all parties involved in the roaming transaction outside the home network. This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network?s operational ownership and Location Information to a Home Service Network. This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network’s operational ownership and Location Information to a Home Service Network. The NetConf protocol needs a way to represent the managed data on a device. This document provides a data model representation along with concrete realizations of system and interface managed objects. This memo defines XML Schema for reporting information about the NetConf system. This document provides motivation for enhancing the NFSv4 protocol to enable checksumming of data and describes extensions to NFSv4 in order to enable such a capability. Discussion and suggestions for improvements are requested. This document describes a format for serializing a DNS record with accompanying DNSSEC information such that a verifier can be convinced that the DNS record is authentic without performing DNS queries itself. This document advocates the usage of small, mostly constant payloads in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show how this can have immediate benefits for some protocols. Additionally, we describe a new TCP option that enables a wider range of protocols to gain from it. This document describes a Transport Layer Security (TLS) extension that allows client certificates to be encrypted in the initial TLS handshake. This document describes a Transport Layer Security (TLS) extension for application layer protocol probing and announcement. This allows the application client to specify which protocol will be performed over the secure connection. This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation. This allows the application layer to negotiate which protocol should be performed over the secure connection. This document describes a Transport Layer Security (TLS) extension for eliminating the latency of handshakes when the client has prior knowledge about the server. Unlike resumption, this prior knowledge is not secret and may be obtained from third parties and stored on disk for significant periods of time. This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. This document provides OSPF extensions to support Generalized Multi- Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs). This document provides RSVP-TE extensions to support Generalized Multi-Protocol Label Switching (GMPLS) control of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs). The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Incremental Zone Transfer (IXFR) is one of the mechanisms and originally was defined in RFC 1995. This document aims to provide a more detailed and up-to-date specification of the IXFR mechanism and to align it with the current specification of the primary zone transfer mechanism, AXFR, given in RFC 5936. Further, based on operational experience, this document juxtaposes to the original IXFR query a new query type, IXFR-ONLY, that will likely be preferred over IXFR in specific deployments. This document obsoletes and replaces RFC 1995. Discussion This draft targets adoption by the DNSEXT working group. Comments should be sent to the authors and/or the namedroppers mailing list. Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. The requirements and procedures for URN Namespace registration documents are currently set forth in RFC 3406, which is also expected to be updated by an independent, revised specification. Discussion This draft version has been obtained by importing the text from RFC 2141 into modern tools and making a first round of updating steps. It is intended to serve as one of the starting points for an effort to bring URN RFCs in alignment with STD 63, STD 68, BCP 26, and the requirements from emerging distributed national and international URN resolution systems, and advance them on the IETF Standards Track. Comments are welcome on the urn@ietf.org mailing list (or sent to the document editor). The objective of this document is to begin a discussion that will determine the level of interest at the IETF in documenting how multiple recovery techniques can successfully be combined to protect a set of network resources and the various interactions between these recovery techniques. Potential outcome of this work could be to define new MIBs and/or OAM techniques devoted to such interactions. This document is an addendum to RFC xxxx, which specifies the real-time transport protocol for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document contains the information related to the new operating mode of VMR-WB. All provisions, restrictions, use cases, features, etc. that are specified in RFC xxxx are applicable to the new operating mode without any exception. No new media type registration is included in this document as the new VMR-WB mode, defined in this document, will use the same media type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the RFC xxxx was developed with sufficient flexibility for future extensions and thereby it allows the addition of new operating modes without any impacts on the interoperability of terminals supporting different versions of the VMR-WB standard. This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of VMR-WB speech data in storage mode applications such as email. A MIME type registration is included, for VMR-WB, specifying use of both the RTP payload and the storage formats that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. Stream Control Transmission Protocol (SCTP) RFC2960 [SXM00] specifications utilize the possible multiple paths between the sender and receiver for retransmission of lost data chunks and as a backup for the primary path, in case of primary path failure. Other than that, all the data chunks are being sent on the primary path chosen by the SCTP user during the association initiation. This memo describes an extension to SCTP that allows endpoints to use the multiple available paths for simultaneous data transmission. The extension maintains SCTP congestion control on each path, so as to ensure fair integration with other traffic in the network. This document describes an address configuration mechanism based on the concept of address pool allocation in the connected MANET. The Internet gateway acts as a DHCP (Dynamic Host Configuration Protocol) server and assigns not a single address but a part of its address pool to an address requesting node and, then, the node can assign a part of its own address pool to its neighbor nodes. By doing this, the address allocation procedure can be expedited. This document describes an enhancement on AODV that can allow a route with more stable intermediate nodes to be selected. For this, a new field, called the 'RouteStability' field, is introduced in the RREQ message and in the AODV routing table entry. This document describes a Domain Name System (DNS) mechanism for the MANET based on the centralized DNS mechanism used in the wired Internet. In order to adapt to the dynamic topology changes of the MANET, the mechanism handles the movement of the DNS server and the MANET merge/partition. In MANET, nodes wishing to communicate with nodes in the wired Internet, the global Internet connectivity is required and this functionality can be achieved with the help of the Internet gateway (IGW). For the support of reliability and flexibility, multiple IGWs can be provisioned for a MANET. In this case, load-balancing becomes one of the important issues since the network performance such as the network throughput can be improved if the load of the IGW is well-balanced. In this draft, we categorize the load-balancing mechanisms for the IPv6-based MANET with multiple IGWs and define a new load-balancing metric computed from the hop distance and the number of routing table entries. This document describes a reliable MANET routing mechanism based on the node mobility detection. To detect the node mobility, each node maintains the Neighbor Node table and measures the stability of its neighboring environment. Using the route stability information, reliabille routing can be achieved. This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a name-to-HIT lookup service and a HIT-to-address lookup service. This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order Aitken, Claise Standard Track [page 1] New Information Elements for the IPFIX Information Model March 2008 to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. While using SIGComp [4] based compression in SIP/SDP [5] [6], it is imperative to have access to a static dictionary to be used on the first SIP message that the compressor sends out. The session set up time can be reduced significantly if the compression rate of the first SIP message is considerably high. The existing static dictionary for SIP and SDP [2], however, does not include some wireless specific data elements. This document introduces these new data elements that are specific to various wireless access technologies. These new data elements are part of the first SIP message (i.e., originating SIP Invite) used to initiate a session. Current SIP messages are text based and inherently large, especially when these messages are to be transmitted over the bandwidth-strained wireless access technologies (a typical orginiating SIP Invite is about 1200 bytes). For most wireless technologies, transmitting the session initiation messages (such as SIP Invite) over the signaling channel can reduce the call setup time substantially. The size limitation of these wireless signaling channels are typically very small (~210 bytes in the uplink and ~110 bytes in the downlink). To address this problem, a new function called Encoding Assitant (EA) has been introduced in the User Agent (UA) and in the SIP Proxy server within the network. Additionally, the method provided in this document defines new SIP option tags and headers. These new option tags and headers allow the UA and a SIP Proxy server within the network (such as the P-CSCF), to exchange information using the signaling channels supported by most wireless access networks. The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of network greater problems. This document describes a generic methodology for calculating metrics related to network based applications. In addition, to the performance metrics, several additional information elements are included to help provide greater context to the reports. The measurements use audio/video applications as base examples but are not restricted to these class of applications. Providing a Standard method for Addition of regional Advertisements in the IP Multicast Video Streaming is very important , because the equipment deployed would most likely be from different vendors across a multicast network. The idea is to introduce a special kind of Enhanced IGMP Ad-Insert control packet, which is passed from the multicast source to intermediate routers and which indicates that the source is going to stop sending multicast traffic for a particular group for specified time and the Regional center can utilize this time to insert its regional advertisement. This document specifies enhancement to the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP Multicast group memberships to neighboring Multicast routers. This enhancement for IGMP adds support for "specifying day, time and duration with Multicast reports", that is, the ability for a system to report interest in receiving traffic for a particular Multicast address at a particular day, time and for a specific duration. This information may be used by intermediate routers and switches to ensure providing better Quality of Service. Also specifying such information in a consolidated packet may help reduce signaling load on the multicast routers. This document specifies a network-based protocol which allows mobile nodes to remain reachable while moving around a certain administrative network called Edge Mobility Domain. This protocol also allows mobile nodes to keep their IP address when the mobile nodes move from one access router to another within the Edge Mobility Domain. Several applications, such as peer-to-peer (P2P), content distribution and realtime services rely on selection mechanisms in order to select the peer or server from which to request the service. Examples of such services are: file sharing, media streaming and voice gateways. Application-layer selection algorithms do not typically take into account network-layer topology information; either that information is unavailable to them, or when such information is available (e.g., from BGP Looking Glass servers), it does not include sufficient information about the local topology in the neighbourhood of the application client(s). Therefore, most applications today make their selection decisions based on performance measurements (combined with some amount of random selection) and largely ignore network layer routing. It has been demonstrated that by keeping the traffic local (e.g., within the same Autonomous System) both infrastructure utilization and application performance may be improved. By enhancing selection algorithms through the use of accurate network-layer topology, applications may improve performance while network operators are also able to reduce the utilization of infrastructure resources by application traffic. At the same time, exchange of information between the application and the network should not be allowed to compromise confidentiality for either party. Detailed routing information owned by the service provider should not be made publicly available, while detailed information about the application should also not be made known to the service provider. This draft introduces a signaling protocol which we call "PROXIDOR". The PROXIDOR protocol is a request-response protocol in which a PROXIDOR Client (PxC) issues requests to and receives responses from a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS and how a PxS acquires network-layer topology information are beyond the scope of this document. The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The contact element in PIDF is understood as a URI. However, some existing Internet services do not identify users (presentities) natively with a URI. Mapping non-URIs to contact element in Presence Information Data Format (Map2PIDF) specifies the mapping of addresses to a URI in the case of such currently existing services. The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The optional contact element in PIDF contains a URI that ultimately resolves to a network interface on some device. Currently, the ways of expressing features related to that interface are limited. PIDFConn defines an extension to PIDF for describing features of connectivities and the cost of using services. This document addresses the problem of providing a bi-directional multicast protocol in an Intranet environment. A protocol named Switched Bi-directional Multicast Protocol (XMP) is proposed. Participants(Sender, S, or Receivers, Rs)signal their will to join the group sending a START(G) packet toward a Focal Point Router(FP). To take control of transmission a receiver application receives permission from the master application (the master transmitter)and sends a START(G) packet re-labeling the involved routers interfaces from R to S. The master Sender resumes transmission by means of his application commanding the receiver's application to go back to the receiver mode and emitting a START(G)packet to FP. ns-2 has been used to simulate it. This document defines a set of extended communities to carry priority information. This information provides a mechanism for assigning a processing preference to the routes that carries it. It also provides a scheme for processing routes with strict priority order during update reception, best-path computation, and update transmission. The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer, the Internet layer ot the DoD model respectively. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. This draft presents a framework document for modeling network elements (NE), facilities, lines, protocols and services for substantially easing development and operation of element manager systems (EMS), network management systems (NMS) and operations support systems (OSS). The framework is independent of the access method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC, etc.) It covers configuration, alarms, current-historical performance, accounting management and security. The frameworks builds on and reuses the existing base of MIBs. The documents presents a light-weight, structured and very simplified framework and method to data modeling for defining and maintaining meta models, device etc. models, and device etc. descriptors. This document provides a framework and methodology for performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and WTPs. This document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such systems, and also supplies the methods used to calculate the expected results of these tests. Specific formats for reporting the results of the tests are also provided, where applicable. The tests described in this document extend the methodology defined for benchmarking network interconnect devices in RFC 2544, and LAN switches in RFC 2889, to WLAN switch controller systems. The methodology herein is to be used together with the companion terminology document. This document provides a terminology to be used when performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and Access Points. The various wireless-specific device nomenclature, as well as the definitions of configuration parameters and test conditions that may be used to characterize the performance of these devices, are provided. The document also defines some of the metrics used during WLAN switch benchmarking. This terminology is to be used in conjunction with the companion methodology document. This document defines the Congestion Status precondition for SIP, utilizing the framework defined in RFC 3312 and updated in RFC 4032. The Congestion Status precondition requires that the participant verify that congestion thresholds along the network path for the session media have not been exceeded before continuing with session establishment or modification. This verification is performed via an RTP probe utilizing draft "Congestion Notification Process for Real- Time Traffic" and draft "RTP Payload Format for ECN Probing". Multimedia Internet Keying (MIKEY) is a key management protocol used for real-time applications. As standardized within RFC3830 it defines four key distribution methods, including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange, with allowances for ready protocol extension. A number of additional methods have been developed and continue to be built from the base protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility and more general applicability, MIKEY and its related extensions have primarily focused on the support of the Secure Real-time Transport Protocol (SRTP). This document specifies a simple adaptation of the MIKEY specification to allow the base protocol and its various key management mode extensions to be readily applied in more general environments beyond the multimedia SRTP domain. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure and introduces a set of message extensions to the base specification to allow the MIKEY key management methods to be applied within Low-power and Lossy networks (LLNs) and other general constrained-device networks. This document describes Admission Control as a use case for the mechanisms described in "Congestion Notification Process for Real-Time Traffic" [1] and the RTP payload format defined in "RTP Payload Format for ECN Probing" [2]. This document describes use cases for the mechanisms described in draft "Congestion Notification Process for Real-Time Traffic" and the RTP payload format defined in draft "RTP Payload Format for ECN Probing". Specifically, it describes admission control and preemption use cases. This memo defines a Real Time Transport Protocol (RTP) payload format for use when probing for congestion using Explicit Congestion Detection (ECN). This payload format is intended for use with the probing mechanisms described in draft "Real-time ECN Use Cases". While defined in terms of the specific application of admission control, it is desirable to overlay this format with other probing mechanisms so as to reduce the number of probing packet formats. This document provides a framework and methodology for performing stress testing and benchmarking of wireless LAN (WLAN) devices, including clients (i.e., host interfaces) and Access Points. The document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such devices, and also supplies the methods used to calculate the results of these tests. This document also describes specific formats for reporting the results of the tests. It extends the methodology defined for benchmarking network interconnecting devices in RFC 2544 and LAN switches in RFC 2889 to IEEE 802.11 WLAN devices. The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. This Internet-Draft provides the description of problem set faced by NFS and its various side band protocols when implemented over IPv6 in various deployment scenarios. Solution to the various problems are also given in the draft and are sought for approval in the respective NFS and side band protocol versions. Foreword This "forward" section is an unnumbered section that is not included in the table of contents. It is primarily used for the IESG to make comments about the document. It can also be used for comments about the status of the document and sometimes is used for the RFC2119 requirements language statement. This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to- router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS- capable Label Switching Routers (LSRs), based on experience gained in interoperability testing. One of the biggest challenges faced by GMPLS technology is “how it can be deployed” in a manner least impacting to existing IP/ MPLS networks. GMPLS architecture document lists [RFC3945] three different scenarios in which GMPLS technology can be deployed: overlay, augmented and integrated. Reference [GMPLS-mig] addresses the problem of migration from MPLS to GMPLS networks using the integrated model. This draft addresses the same problem space for augmented model and illustrates the applicability of augmented model in deploying GMPLS technology in existing IP/ MPLS networks. Z. Ali, et Al. Expires August 2008 [page 1] Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 [RFC4379] describes procedures for ping and tracerouting for LSPs with PSC (packet switch capable) transit switching capability. An important implication of using transparent (non-PSC) nodes in GMPLS network is that LSP Ping solution described in [RFC4379] are not applicable to LSP with non-PSC switching capability. Another important difference between PSC and non-PSC switching technologies is the data and control plan separation in the latter case. An implication of the separation of data and control planes in GMPLS networks is that LSP traceroute procedures described in [RFC4379] are not directly applicable to GMPLS networks with separation of data and control planes. The scope of this draft is cases where data plane does not provide the OAM functions addressed by this draft. This document is assumed that OAM mechanisms provided by the underlying data plan technology MUST be used, whenever possible. E.g., G.709 addresses the problem of trace routing in DWDM network. However, G.709 OAM mechanisms are only applicable to OEO (Optical-Electrical-Optical) capable node. This document fills in such gaps; in particular it addresses GMPLS OAM functionality in optical networks with wavelength routers, ROADMs nodes, etc. with no OEO conversion capability. For this purpose, the draft relies on control plan mechanism to provide required OAM functions. Specifically the proposed solutions are based on Link Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473] and do not require any extension to the data plan. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. GMPLS-TE Graceful shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. GMPLS-TE graceful shutdown mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable for both MPLS and its GMPLS extensions. Ability to administratively shutdown RSVP Hellos and Graceful Restart (GR) procedure without impacting the traffic is a desirable network operation. Furthermore, there are applications that run RSVP Hellos with intervals on the order of milliseconds. This poses a requirement to reduce the number of RSVP messages to a minimal required count. Fortunately RSVP Hellos are not mandatory and are only required to run when needed. This allows applications to remove an RSVP Hello session, when it is not needed. This ID proposes a procedure to remove RSVP Hello and/ or GR sessions for administrative or optimization purposes. Use of node-id based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. The problem of path validation of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical impairments related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical impairments measured over optical nodes along the light-path. Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address many issues that comes when a P2MP-TE LSP is signaled in an inter-domain networks. Specifically, one of the issues in inter-domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is re-merge free. This document provides a framework and required protocol extensions needed for establishing and controlling P2MP MPLS and GMPLS TE LSPs in inter-domain networks. This document borrows inter-domain TE terminology from [RFC 4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. One of the management requirements for point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is the ability to identify source-to-leaf (S2L) sub-lsp by name. This document provides a minor extension to RSVP-TE for P2MP TE LSPs [RSVP-TE- P2MP] to signal name for S2L sub-lsp. There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object [RFC3471], [RFC3473]. The document proposes use of some dedicated PID values to cover some typical cases of multiple payloads carried by the LSP. The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement [PCEP-P2MP-REQ]. This document addresses this requirement by extending backward recursive path computation (BRPC) technique proposed for Point-to-Point (P2P) LSPs in [P2P-BRPC] for P2MP LSP path computation in a multiple domains network. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of P2P applications is to introduce storage capabilities within the network. The DECADE Working Group has been formed with the goal of developing an architecture to provide this capability. This document presents an architecture, discusses the underlying principles and identifies core components and protocols supporting the architecture. This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This document proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. This document is a framework for how data plane OAM functions can be applied to operations and maintenance procedures. The document is structured to outline how OAM functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. Provider Backbone Transport (PBT, known as well as PBB-TE and progressed in IEEE as 802.1Qay [802.1Qay]) provides a mechanism where native Ethernet point-to-point tunnels can be configured or signaled across a provider-based Ethernet network [FEDYK]. PWE3 architecture defines a mechanism, called pseudowires, that emulates the essential attributes of a layer-2 and layer-1 service over a Packet Switched Network (PSN). This draft describes the architecture and procedures where Pseudowires are carried across PBT tunnels. In this proposal PBT tunnels are used as the PSN. Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. Internet Draft Comments Comments are solicited. Please include the AFS Standardization mailing list at afs3-standardization@openafs.org as a recipient of any comments. 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. This specification defines how the Uniform Resource Name namespace reserved for GSMA (Global Sstandard for Mobiles Association) identities and its sub namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of FITS files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged using FITS. This document describes a private Session Initiation Protocol(SIP) header (P-header) used by the Open Mobile Alliance (OMA), for Push- to-talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset which is particular to the PoC application. This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance (OMA),For Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. The P-headers are used for requesting and indicating the alerting mode of the handset which is particular to the PoC application. DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting message sender identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Proof and protection of email identity, including repudiation and non-repudiation, may assist in the global control of "spam" and "phishing". DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in This document describes the records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results. This document sketches a potential quality control mechanism for the IETF in the form of working group review committees. The idea is to form a small committee per working group that will provide document review and advice throughout the working group's lifetime. This document describes a method for using spurious retransmission timeouts as the trigger for slightly changing the way TCP's retransmission timeout is computed in an effort to avoid subsequent unnecessary retransmissions. 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. This document specifies the progression of initial TCP congestion window sizes over the next nine years. This document provides for high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. In this document we aim to solve several problems caused by TCP's lack of header space for certain values by increasing the size of header without changing the semantics of the protocol. This document describes the authentication option to the Telnet protocol, RFC 854, as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the Telnet authentication option, RFC 2941, to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option, RFC XXXX. This document describes how Kerberos Version 5 [RFC 4120] is used with the Telnet protocol [RFC 854]. It describes an Telnet Authentication suboption to be used with the Telnet Authentication option [RFC YYYY]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the Telnet Encryption option [RFC 2946]. This document updates a previous specification of the Telnet Authentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5 Telnet authentication to be used in conjunction with the START_TLS option [RFC XXXX]. This document specifies an authentication scheme for the Telnet protocol [RFC 854] under the framework described in [RFC YYYY], using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945]. This document updates a previous specification of the Telnet Authentication SRP method, RFC 2944, to allow SRP Telnet authentication to be used in conjunction with the Telnet START_TLS option [RFC YYYY]. Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding). As ALTO specification continues in the ALTO Working Group and some applications start to conduct integration with ALTO, more ISPs start to evaluate key issues in the deployment of ALTO in their networks. In this document, we discuss key issues that an ISP needs to consider when deploying ALTO. In particular, we disucss issues on how to configure ALTO information as well as how to monitor the effectiveness of ALTO. Application-Layer Traffic Optimization (ALTO) guides an application, especially a Peer to Peer (P2P) application, to select hosts from its candidate set. ALTO is a promising technique for future network, as it is able to jointly optimize network resource utilization and application performance. The ALTO protocol is Client-Server based. Applications work as ALTO clients to fetch PID information from the ALTO server, but the ALTO server can't send the notification to ALTO clients, even if there is a major change to the networks. This draft discusses the requirements for server initialized notification, and proposes one mechanism to enable the ALTO server notification. This document follows up the observations and recommendations outlined in the IAB Advisory Committee report ([1]) with a statement of purpose for the administration restructuring proposed in [3]. A high level definition of the IETF's purpose can be found in [2]. All 4 documents are meant to be read collectively. This document describes a combination and profiling of existing IETF protocols to provide a datagram service that is suitable as a generic transport substrate for the RTC-Web family of real-time audio/video applications. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, with the intended discussion forum being the "RTCWEB" WG (in formation). Currently, discussion is on the rtc-web@alvestrand.no mailing list. This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. This document gives an outline of a way to put together review teams for documents in late review (pre-approval time). It is intended as input to the ICAR WG. Comments are welcome, and can be directed to the editor or to the ICAR mailing list <icar@ietf.org> The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI criterion for IDNA labels. This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than internet-drafts, and with more clear handling procedures than a random Web page. It proposes to establish this series as an RFC 3933 process experiment. This document describes a procedure for performing the downgrading of old standards described in RFC 2026, as well as BCPs, without placing an unreasonable load on groups charged with performing other tasks in the IETF. This document describes a procedure for performing the downgrading of old Proposed and Draft standards described in RFC 2026 without placing an unreasonable load on groups charged with performing other tasks in the IETF. It defines a new group, called the 'Commission for Protocol Obsolesence', which shall recommend to the IESG downgrading or progressing documents on the IETF standards track. Ultimate decisions still rest of with the IESG, with appeal to the IAB. This document describes an extension to the Session Description Protocol (SDP) to describe RTP sessions where media of multiple top level types, for example audio and video, are carried in the same RTP session. This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for consideration. This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" is carried using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a candidate to become a work item of the RTCWEB working group. This document is not intended for publication as an RFC. It gives the underpinning arguments for why the idea that RTP sessions and MIME top level types are related is a deeply broken paradigm, and that we need to get away from it. These arguments are solely the opinion of the listed author. This document describes the IETF's procedures for handling subpoenas served on the IETF. This is an adaptation of the ad-hoc procedures that the IESG has applied for recent such events, taking account of the creation of the IETF Administrative Support Activity (IASA). This document describes an improved IS-IS neighbor management scheme which can be used to enhance network performance by allowing operators to quickly and accurately shift traffic away from a point- to-point or multi-access LAN interface by allowing one IS-IS router to signal to a second, adjacent IS-IS neighbor to adjust its IS-IS metric that should be used to temporarily reach the first IS-IS router during network maintenance events. Current IP and MPLS OAM techniques need to be extended to permit operators to effectively diagnose load-balancing issues. Specifically, new ad-hoc OAM techniques are needed to diganose various link-bundling techniques, such as IP/MPLS Equal Cost Multi- Path (ECMP) and Link Aggregation Groups (LAG). In addition, these OAM tools should also be extended to permit performance monitoring over longer time durations. This document defines requirements for the next generation of OAM solutions. This draft specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer. While Quick-Start is designed to be used by a range of transport protocols, in this document we describe its use with TCP. By using Quick-Start, a TCP host, say, host A, would indicate its desired sending rate in bytes per second, using a Quick Start Request option in the IP header of a TCP packet. A Quick-Start request for a higher sending rate would be sent in a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start request is not approved. If the Quick-Start request is not approved, then the sender would use the default congestion control mechanisms. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick- Start Request option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport-level Quick-Start Response in an answering TCP packet. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and all of the routers along the path support the Quick-Start Request. RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see <https://www.ietf.org/mailman/listinfo/apps-discuss>). This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance. This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. Source port randomization has been suggested to provide improved security and obfuscation which helps in adding robustness towards blind attacks. With TCP in practice, simply producing a random port as the source port for a new connection can lead to problems when a TCP client establishes connections to a TCP server at a high rate. If the same source port value is chosen twice, the client TCP connection can fail due to the server having the Transmission Control Block (TCB) for this tuple lingering in TIME-WAIT state. This memo discusses the ramifications of such source port reuse scenarios and suggests some mitigations to avoid the same. This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs. This memo defines a portion of the Management Information Base (MIB) for managing NAS (Network Access Server) that are using Access Node Control Protocol (ANCP). This document describes proposed extensions to the ANCP protocol to allow a graceful recovery of an ANCP session and associated information after an existing session is reset. Such a reset may be due to a NAS restart , or a loss of connectivity between the NAS and the AN. Translation of IP addresses to domain names is an optional feature of DNS. Many sites implement it in someway, many others do not implement it at all. Over time, some myths have developed regarding reverse DNS mapping. The goal of this document is to to identify best practices, illuminate false assumptions and to report on the status of reverse DNS facilities so that DNS Administrators and operators can make informed decisions about the options for DNS reverse mapping. This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. This document specifies the extensions to RSVP-TE that Acreo AB has used in the GMPLS part of testbed. Whenever IETF decides to enter into a liaison relationhsip with another organization, e.g. a Standards Development Organization, a consortium, or an industrial forum, a liaison manger is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052 [RFC4052]. This document give guidelines on expectations, tasks, responsibilities and mandate of the liaisons managers. - Table of Contents At first glance the acronym "OAM" seems to be well known and well understood. Looking at it a bit more closely reveals a set of recurring problems that are revisited time and again. This document has one primary and a secondary goal. The primary goal is to find an understanding of OAM that is feasible for the MPLS Transport Profile (MPLS-TP)effort. The secondary goal is to make this understanding applicable in a wider scope The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile in cooperation between IETF and ITU-T does not fully define and document processes for development of the required RFCs. This document complements the processes documented in the JWT decision with a few separate elements; it: o provides an adaptation of the IETF working group process, o identifies the expected participation in the process by the ITU-T, o clarifies the decision rules regarding MPLS-TP documents. This document is not intended to specify any ITU-T process; to the extent necessary ITU-T activities will be done according to ITU-T process/rules. Nor is this document is intended to specify the IETF working group process, it is limited to the temporary adaptations of that process that is the result of that IETF and ITU-T accepted the proposal in the JWT report to jointly develop the MPLS Transport Profile. In general it may be said that these adaptations are introduced to ensure a good and consistent document review across the two organizations. This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. 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. This document defines a new connectivity precondition for the Session Description Protocol precondition framework described in RFC 3312. A connecitivity precondition can be used to delay session establishment or modification until media stream connectivity has been verified successfully. The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP and RTP with RTCP-based feedback. The purpose of this document is to identify a set of requirements for SDP Capability Negotiation and evaluate existing work in this area. The document does not provide any solutions to SDP Capability Negotiation The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP and RTP with RTCP-based feedback. The purpose of this document is to address that by identifying a set of requirements, evaluate existing work in this area, and provide a recommended solution for extending SDP with capability negotiation. The current SDP Capability Negotiation solution includes the ability for a potential configuration to delete and replace individual attributes from the actual configuration. This capability introduces some complexity into the SDP Capability Negotiation framework and this document examines the need for having this feature and proposes a way forward. This document defines a new security precondition for the Session Description Protocol precondition framework described in RFC 3312. A security precondition can be used to delay session establishment or modification until media stream security has been negotiated successfully. In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a mechanism to force a Fragment header to be added to a packet. This document defines a new DNS Resource Record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. 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. Idn users have expressed a need to have multiple labels be treated as one in the DNS. This document presents a method to do this by defining a new label type that ties a set of labels together that need to be treated indentically. Sometimes it is necessary to discover the Start of Authority points in the DNS, otherwise known as zone cuts, without causing negative entries to be recorded in caches. This document describes how to achieve this. This document provides advice to DNS developers about sending DNS UDP messages and Path MTU Discovery. Practice has shown that there are a number of zones all full service resolvers should, unless configured otherwise, automatically serve. RFC4193 already specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC1918 address space and other well known zones with similar usage constraints. Provides a DHCP 6to4 Relay Router option. This document describes the implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA), Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This specification defines a new SIP dialog event package tag "appearance" and a method for a group of SIP user agents to coordinate the identification of appearances between them using SIP dialog package subscriptions. The PANA protocol provides a means to authenticate clients in an IP network using cryptographic credentials. This document identifies scenarios where there may be a need for a client to provide location credentials, in addition to cryptographic credentials, to gain network access. This document also enumerates the requirements for PANA support of location based services. This document describes a protocol for dynamically determining CE/FE element bindings discovery and inter-FE topology discovery and maintenance. Such a mechanism is needed for all these elements in the set to behave as a single network element, as required by the ForCES architecture. The discovery protocol operates during both the pre-association and post-association phases of ForCES protocol. This document introduces the use of triggers coming from layers higher than the link layer to initiate the Low Latency Handoff in Mobile IPv4 (MIPv4) . The Low Latency Handoff for MIPv4 assumes availability of Layer 2 (L2) triggers that contain Layer 3 (L3) information for the Mobile Node (MN) to handoff. However, the low latency draft does not describe the method by which the L2 trigger is produced neither does it explicitly describe by what mechanism the L3 information present in the L2 trigger is acquired. The Low Latency Handoff for MIPv4 relies on availability of the L2 trigger. However relying only on the link information to initiate a handoff does not generally gather enough information for the MN to handoff to the most suitable available access network. Information from higher layers such as Higher Layer Triggers can be used to command a MN to quickly move from one access to another one. Using Higher Layer Triggers to initiate the handoff enables the implementation of policy based handoff to garantee load balancing of the wireless networks and Quality of Services to the end users. The simultaneous use of Mobike and Mobile IPv4 has been proposed to provide secure connectivity and session continuity to roaming corporate users. Optimization of this solution have eliminated the tunneling overhead of Mobile IPv4 in the vpn tunnel by having a Foreign Agent co-located to the mobile vpn gateway. This document further proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. The mobile vpn gateway is co-located to the Mobility Proxy Agent and each Access Point in the corporate network is equipped with Proxy Mobile IP. When moving outside the corporate network, the Mobile Node secure connectivity and session continuity is handled by Mobike. Proxy Mobile IP alone is used to handle mobility when the Mobile Node moves within the corporate network. This document introduces an interaction between Internet Key Exchange v2 and Proxy Mobile IP in which the Internet Key Exchange AUTH request triggers the Proxy Mobile IP registration request to the internal Home Agent. This interaction easily allows the Mobile Node's home address to be used as vpn Tunnel Inner Address. There is a class of data serving protocols and applications that cannot tolerate undetected data corruption on the wire. Data corruption could occur at the source in software, in the network interface card, out on the link, on intermediate routers or at the destination network interface card or node. The Ethernet CRC and the 16-bit checksum in the TCP/UDP headers are used to detect data errors. Most applications rely on these checksums to detect data corruptions and do not use any checksums or CRC checks at their level. Research has shown that the TCP/UDP checksums are catching a significant number of errors, however, the research suggests that one packet in 10 billion will have an error that goes undetected for Ethernet MTU frames (MTU of 1500). Under certain situations, "bad" hosts can introduce undetected errors at a much higher frequency and order. With the use of Jumbo frames on the rise, and therefore more data bits on the wire that could be corrupted, the current 16-bit TCP/UDP checksum, or the Ethernet 32-bit CRC are simply not sufficient for detecting errors. This document specifies a proposal to use stronger checksum algorithms for TCP Jumbo Frames for IPv4 and IPv6 networks. The Castagnoli CRC 32C algorithm used in iSCSI and SCTP is proposed as the error detection code of choice. The Uniform Resource Identifier (URI) scheme "arib:" has been devised to allow acquiring the current or future scheduled publications of broadcast media content from the internet. These broadcast media contents are distributed with the MPEG-2 TS [ISO/IEC 13818-1] on the ISDB (Integrated Services Digital Broadcasting) broadcast system, which is specified in the [ITU-R BT.1306] and [ITU-R BS.1114]. This document describes best current practices that community administrators should use when interconnecting two or more instant messaging and presence communities using SIP/SIMPLE. These best practices are intended to assist in the efficiency and scalability of interconnections between large communities, and to ensure that security and user privacy are maintained across the link between communities. The purpose of this document is to serve as the reference for the SIP/SIMPLE community towards inter-domain interoperability and also to identify new requirements specific to the inter-domain interface. This document discusses NAT/FW NSLP issues and solutions for cases where NATFW NSLP NEs within the same addressing realm communicate with each other. The document will serve as input to the NSIS NAT/FW NSLP document to meet these intra-realm communications' requirements. This document discusses migration issues towards NSIS NAT/FW NSLP enabled NATs and Firewalls. In particular traversal of NSIS unaware NATs and NSIS proxy scenarios are addressed. This document will serve as input to the NSIS NATFW NSLP document. This document discusses reasons why use of the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766 should be deprecated and RFC2766 moved to historic status. Description of an alternative protocol translation mechanism is out of scope for this document. This memo introduces the status of study in Japan regarding the communication for emergency reports using public IP telephony services. First, it provides the information on the background and history, and then it summarizes the functional requirements from the relevant authorities. This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality for Service Protocol (Q4S) provides a mechanism for latency, jitter, bandwidth an packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependant (e.g. increase quality, reduce bit-rate) or even network dependant (e.g. change connection's quality profile). This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality HTTP (Q-HTTP) provides a mechanism for latency, jitter, bandwidth an packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependant (e.g. increase quality, reduce bit-rate) or even network dependant (e.g. change connection's quality profile). This document discusses policy concepts for management of Quality of Services (QoS) of applications in heterogeneous Internet environment. A framework is given for definitions of policies for configuration and automated adaptation of network resources, application transport parameters and QoS measurement scenarios dependent on the capabilities of heterogeneous access networks. Currently, the IETF QoS policy work is aimed at "specifying and representing policies that administer, manage and control access to network QoS resources" based on DiffServ and IntServ technologies [5]. To enhance this model, policies for management of QoS of heterogeneous network infrastructures are proposed in this document. Based on the capabilities of heterogeneous access networks, the QoS policies for heterogeneous environment allow dynamic configuration and adaptation of network resource reservations, application transport parameters and QoS measurement scenarios. The policies are defined for different actors, such as users, application service providers and network operators. The hierarchical policy management is based on rules specifying adaptation of parameters of policies of actors with hierarchical relationships. This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). This document is aimed at presenting Access Node Control Protocol (ANCP) with vendor specific protocol extensions. This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document outlines a solution to relax that restriction and allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. As multicast networks start to get deployed in large number, it becomes very important that, proper mechanisms are in place for trouble shooting error conditions and informing other failure situations. Since multicasting has little support from IP in this matter (since ICMP does not support multicasting and broadcasting) it behooves that, multicast routing protocols, embed these features in themselves. This draft presents some ideas about how this can be done using PIM protocol suite as example, since PIMSSM and PIMSM are probably most widely used multicast routing protocols. This document defines the DNSSEC Lookaside Validation Pointer (DLVPTR) Resource Record (RR), for publishing pointers to DNSSEC Lookaside Validation (DLV) records. This document clarifies DNS response message interpretation to avoid denial of service attacks using DNS responses. In a recent DNS software assessment it has come to light that some implementations respond to DNS response messages. A loop occurs if the receiver of this response responds with a response. It was never explicitly stated that response messages must not be answered. This draft makes the statement explicit. This document describes the DNSNR Resource Record (RR) for the Non-Repudiation (NR) of Existence service in the context of the DNS Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or "Authenticated Denial of Existence" Resource Records. A signed DNSNR RR protects security-aware DNS components against false denial of existence of RRsets by providing the RR types that exist for its ownername, which optionally includes a non-authoritative delegation point NS RR type. Labels in the ownername and the RDATA may be a hash-value as a defense against zone traversal. This document describes the Name Server Control Protocol (NSCP). The NSCP will permit the management of diverse name server implementations. The NSCP uses NETCONF as framework. This document specifies the format and contents of Data Escrow deposits for Domain Name Registration Organizations. This document specifies the format and contents of Data Escrow deposits for Domain Registries. This document examines how policy conflicts happen, and how to address the conflicts. After making it clear what kind of address selection policy should be necessary, we proposed how to merge the possibily conflicting policies for each of the destination address selection policy and source address selection policy. In response to address selection problem statement and requirement documents, this document describes approaches to solutions and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability of each solution mechanism from the viewpoint of practical application. RFC 3484 has several known issues to be fixed. Deprecation of IPv6 site-local unicast address and the coming of ULA brought some preferable changes to the rules. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these points to be fixed and proposes possible useful changes to be included in the revision of RFC 3484. This document describes a Neighbor Discovery IPv6 Source Address Selection(SAS) Policy option for distributing of source address selection policies to end nodes. This option is particularly effective when a consumer site has multiple address blocks. Every end node is guided by such a policy in selecting an appropriate source address for each destination address. This makes it possible for an end node to set up a connection without concern for transfer failures due to ingress filtering by ISPs, for ISP operators to manage user behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. This document describes some practical usages of address selection policy distribution mechanism defined in another document. Address selection policies are originated by ISPs or by network administrators and are delivered to each end host. These policies are stored at end hosts in the form of default address selection policy table. This mechanism enables central control of address selection policy at end hosts, so it is essential or helpful in many cases, such as IPv4 and IPv6 dual-stack environment and ULA and Global address parallel-use environment. RFC 3484 has several known descriptions to be modified mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. This document covers these essential points to be modified and also possible useful changes to be included in the revision of RFC 3484. This document describes a method for the distribution of source address selection policy from ISPs to gateway routers for consumers and from the gateways to end nodes. This method is particularly effective when a consumer site has multiple address blocks. Every end node is guided by the policy in selecting an appropriate source address for each destination address and every gateway is guided by the policy in forwarding packets to appropriate next-hop ISPs. This makes it possible for an end node to set a connection up without being concerned about failures of transfer due to ingress filtering by the ISPs, for ISP operators to manage consumers' behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. This document describes a method for the distribution of source address selection policy from ISPs to gateway routers for consumers and from the gateways to end nodes. This method is particularly effective when a consumer site has multiple address blocks. Every end node is guided by the policy in selecting an appropriate source address for each destination address and every gateway is guided by the policy in forwarding packets to appropriate next-hop ISPs. This makes it possible for an end node to set a connection up without being concerned about failures of transfer due to ingress filtering by the ISPs, for ISP operators to manage consumers' behavior and networking policy, and for consumers to be provided with networks that are almost automatically robust and reliable. The existing transport protocols aren't designed to work well on multi-homed and multi-addressed hosts. TLC-FM is a transport layer common framework, which stores multihoming related information and provides common functions and multihoming functions for all the transport protocols. In this framework, address information for each remote host and some routing information for each next-hop is stored and shared by each transport protocol. Also in this framework, incoming packet's address fields are re-written from the on-wire address to the original one that is expected by transport protocols. This is true for outgoing packets as well. When an ISP tries to deploy IPv6 and take an action for IPv4 address depletion, DS-Lite is reasonable approach for solving both of the problems. However, it is troublesome for an ISP to have the existing IPv4 service facilities and DS-Lite facilities at the same time for not a short period of time. This document proposes a mechanism to assign an IPv4 global address in DS-Lite framework, which makes every customer to move to DS-Lite based network, and enables an ISP to maintain single facility of the service network. One physical network can carry multiple logical networks. Moreover, we can use multiple physical networks at the same time in a host. In that environment, end-hosts might have multiple IP addresses and be required to use them selectively. Without an appropriate source/ destination address selection mechanism, the host will experience some trouble in the communication. RFC 3484 defines both the source and destination address selection algorithms, but the multi-prefix environment considered here needs additional rules beyond the default operation. This document describes the possible problems that end- hosts could encounter in an environment with multiple logical networks. In response to address selection problem statement and requirement documents, this document describes approaches to solutions and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability of each solution mechanism from the viewpoint of practical application. Proxy Mobile IPv6 (PMIPv6) provides the Internet connectivity to Mobile Node in a PMIPv6 domain. Current PMIPv6 specification supports only Host Mobility. In order to support a network mobility, this document defines Proxy Mobility Protocol that provides and maintains the connectivity for the Mobile Network Node (MNN) in the mobile network (nemo). This document discusses the deployment consideration of PNEMO and proposes the possible solution accordingly. This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. Constrained Application Protocol (CoAP) is a light-weight protocol designed to be used in machine-to-machine applications. This memo describes challenges associated with securing CoAP and proposes a new security model that the authors believe is suitable for these environments. The model requires minimal amount of configuration, but still provides strong security and is a natural fit with the typical communication practices smart object networking environments. This memo also proposes JSON payload format extensions to support the architecture. The authors are developing COAP and IPv6-based sensor networks for environments where lightweight implementations, long battery lifetimes, and minimal management burden are important. The memo shows how different communication models supported by COAP affect implementation complexity and energy consumption, far more so than mere changes in message syntax. Our prototype implements a multicast-based IPv6, UDP, COAP, and XML protocol stack in less than 50 assembler instructions. While this extremely minimal implementation is suitable only for limited applications and makes a number of assumptions, the general conclusions point to need for further work in developing the COAP multicast and observation frameworks. This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. EAP is typically used in an arrangement where the actual service (such as a wireless LAN access point) is separated from the authentication server. However, EAP itself does not have a concept of a service identity or its parameters, and thus the client usually does not authenticate any information about the service itself, even when a mutually authenticating EAP method is used. This document specifies a backward compatible extension to popular EAP methods for authenticating service related information, such as the identity and type of the offered service. A common parameter name space is created in order to ensure that the same kinds of identifiers can be authenticated independent of the choice of the EAP authentication method, retaining the EAP media independence principle. This memo describes a prefix assignment mechanism for home networks. It is expected that home gateway routers are assigned an IPv6 prefix through DHCPv6 Prefix Delegation (PD). This prefix needs to be divided among the multiple subnets in a home network. This memo describes a mechanism for such division via OSPFv3. This is an alternative design to using DHCPv6 PD also for the prefix assignment. The memo is input to the working group so that it can make a decision on which type of design to pursue. It is expected that a routing- protocol based assignment uses a minimal amount of prefixes. This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and recommends ones that have been found to work well in operational networks in many common situations. The Mobile Application Part (MAP) protocol is a signaling protocol for cellular networks. The MAP Security (MAPSEC) protocol provides a secure way to transport MAP messages. To use MAPSEC, however, Security Associations (SAs) are needed. This document defines how such SAs can be created automatically. We use the Internet Security Association and Key Management Protocol (ISAKMP) as a framework for managing SAs and establishing keys. The framework can be specialized to a particular task. Such a specialization is called a Domain of Interpretation (DOI), and this document defines the MAPSEC DOI. This specialization is very similar to the Internet Key Exchange protocol and the ISAKMP specialization for IP Security, except that non-IP protocols are being negotiated. This document revises the RFC 3775 rules on how Alternate Care-of Address option is processed. Alternate Care-of Address option is used to carry the current care-of address inside a Mobility Header message. This is used in addition to the source address in the packet in order to ensure that the care-of address is protected by IPsec ESP, the security mechanism that protects Mobility Header messages. Unfortunately, RFC 3775 did not require verification that the source address and care-of address are the same. This document adds that requirement. This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, 6043, and obsoletes RFC 4909. This specification extends IPv6 Neighbor Discovery with features that are useful for mobile nodes. These features provide information for the purposes of detecting the loss of Router Advertisements, determining the global address of the router, or for discovering which routers are also Mobile IPv6 home agents. These extensions are required for Mobile IPv6 operation, but they are also useful for any type of nomadic or mobile nodes. This document revises a part of RFC 3775 which originally defined these extensions. The Mobile IPv6 mobility-management protocol enables minimum routing paths between a mobile node and a correspondent node, which may itself be mobile. This feature is called route optimization. Route optimization requires authorization of initially unacquainted and untrusted parties. A so-called return-routability procedure was integrated into the Mobile IPv6 in order to do this securely. The return-routability procedure equips the mobile node with cryptographic tokens that authenticate the mobile node and prove the mobile node's presence at a claimed new location after movement. Recently, a number of improvements or optional alternatives have been suggested to the standard procedure. The primary driver between these improvements is oftentimes further reduction of signaling messages and latency, but other improvements such as better security have also been suggested. This document discusses the potential goals for future enhancements of route optimization, the security threats that such enhancements must consider, and the various enhancement proposals and their key ideas. An evaluation of some recent proposals is included, as well as a discussion of how significant the Mobile IPv6 related optimizations are related to other ongoing optimization efforts. Finally, needs for future research are outlined. This document proposes an enhanced security mechanism for Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. Mobile IPv6 return routability mechanisms require home and care-of address keygen tokens to be used to authorize a binding update to correspondent nodes. The current rules dictate that such authorization be performed every seven minutes, using tokens at most three and half minutes old. This requirement results in an average signaling traffic of around 7 bits per second when the hosts are not moving around. This traffic load by itself is neglible, but can be problematic for hosts in standby mode. We present a secure and lightweight extension of return routability that can reduce this signaling load to around 0.1 bits per second, and require hosts to wake up much less frequently. This draft discusses locator pair selection and failure detection mechanisms for the IPv6 multihoming feature being developed in the Multi6 working group. Elements of this document may also be useful for developing the details of the MOBIKE or HIP multihoming mechanisms. The draft also discusses the roles of a multihoming protocol versus network attachment functions at IP and link layers. Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to- peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution. This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). This document specifies the IANA guidelines for allocating new values in the PPP Bandwidth Allocation and Bandwidth Allocation Control Protocols. This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Authentication and Key Agreement (AKA) mechanism used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and cdma2000. AKA is based on symmetric keys, and runs typically in a Subscriber Identity Module (UMTS Subscriber Identity Module USIM, or (Removable) User Identity Module (R)UIM), a smart card like device. This draft relates to the use of Authentication, Authorization, and Accounting (AAA) where the same user credentials can be used on many different types of devices, ranging from wireless access points to Virtual Private Network (VPN) gateways. This draft discusses how to use existing AAA and authentication protocols and extensions to determine what service was provided, agree about this among all the participating parties, and use this information as a basis for policy decisions. This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during, for instance, PPP and wireless LAN authentication. 'Roaming' may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP 'confederations' and ISP-provided corporate network access support. This document is a revised version of RFC 2486 which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time, but hopefully also helps understand the rationale behind current IETF tools for co- existence and transition. This memo focuses on the evolving networking technology within and among relatively small "residential home" networks. The goal of this memo is to define the architecture for IPv6-based home networking that supports the demands placed on it. This architecture shows how standard IPv6 mechanisms and addressing can be employed in home networking, and outlines the need for specific protocol extensions for certain additional functionality. The continued growth of large-scale data centers has resulted in a wide range of architectures and designs. Each design is tuned to address the challenges and requirements of the specific applications and workload that the data is being built for. Each design evolves as engineering solutions are developed to workaround limitations of existing protocols, hardware, as well as software implementations. The goal of this document is to characterize this problem space in detail in order to better understand if there is any gap in making address resolution scale in various network designs for data centers. In particular it is our goal to peel back the various optimization and engineering solutions to develop generalized reference architectures for a data center. We also discuss the various factors that influence design choices in developing various data center designs. IKEv2 is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently the IKE SAs and tunnel mode Ipsec SA's are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPSEC packets (transport mode IPsec SAs are beyond the scope of this document). This document defines an IKEv2 extension that allows the outer tunnel header addresses for the tunnel mode IPSEC packets to be different than the IKE peer IP addresses. This document describes a Quality of Service model (QOSM), for networks that support the use of the Controlled load service over a Diffserv cloud using pre-congestion notification. Ths is a technique to perform admission control in a Diffserv network by measuring the congestion level in a domain. New flows are admitted only if the current congestion level is below the allowed threshold. When the controlled load in a domain exceeds a certain threshold, the egress prompts the ingress to pre-empt certain flows. This proposal is based on the proposal made by B.Briscoe et al., for the extension of RSVP to support the Controlled load service over a Diffserv cloud using pre-congestion notification. This document describes an optimization for MLDv1 (RFC 2710) and MLDv2 (RFC 3810). As per this optimization, a new router on coming up will not send periodic "General Query" messages to get the list of multicast listeners. Instead, it will try to get the same from the Querier on the link. Only if no Querier are present on the link, will the new router move to Querier state and send "General Query" messages. This approach provides an advantage in eliminating possibly large number of "Multicast Listener Report" messages every time a new router comes up on a link. More the number of listeners on a link, more the advantage. This draft presents a mechanism to simplify one of the cumbersome aspects of mailing, when one needs to send mails only to a subset of mail-ids from an alias [ALIAS] . The basic intention is only to minimize the complication and difficulty of a mail user when a mail needs to be sent to n - m mail IDs i.e. send it to a group Id of n and exclude m from the alias [ALIAS] list. The X500 Directory specifies an encoding of Presentation Address, which utilizes OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. X500 Directories not being heavy users of OSI Session layer services can be run in a pure TCP/IP environment. This is possible by incorporating minimal OSI presentation and session layer services in the X500 Directory, thus allowing the X500 Directory to run in a pure TCP/IP environment. This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. This document describes requirements and rules for multicast packets to be filtered in IP before sending it to the upper layer protocols like TCP or UDP. This document describes a Prefix Delegation Mechanism which delegates IPv6 prefixes to a subscriber's network (or "site") by an Internet Service Provider (ISP). It uses ICMPv6 messages to handle Prefix Delegation between the Delegating Router and the Requesting Router. This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistance with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency). This document describes the IGMP and the ICMPv6 multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special packet types and implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the new router functionality. Multicast traceroute requires a special packet type and implementation on the part of routers. This document describes the IPv6 multicast traceroute facility. The main aim of this document is to clarify the difference between IPv4 multicast traceroute [5] and IPv6 multicast traceroute. The Session Announcement Protocol (SAP) [2] has historically been used to announce information for all available IP multicast sessions to the prospective receivers in the experimental MBone. Each receiver can then discover which sessions are available and which ones he may want to join. Although SAP is easy to use, SAP is not scalable and controlling the SAP message transmission in a wide area network is not easy. Therefore this document describes the limitations of SAP when used in the global Internet. Furthermore, SAP has recently been used as a convenient method for conveying configuration information to a set of receivers that are already interested by a multicast session (e.g., to carry FEC Framework Configuration Information [7]). This documents describes the limitations of SAP for this type of usage, since this latter is rather different from its original goals. The Session Announcement Protocol (SAP) [3] was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is usefull and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several major limitations SAP has and the requirement of multicast session announcement in the global Internet. This document defines an architecture for the access of Internet Media Guide (IMG) metadata. An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document proposes a common architecture that provides the IMG access methods, including the use methods of URN and IMG Envelope. This document describes an explicit membership notification operation and IGMP and MLD Hold and Release protocol extensions for hosts and routers. The interoperability with the standard IGMPv3/MLDv2 protocols and these previous versions is also taken into account. IGMP and MLD are the protocols used by hosts to report their IP multicast group memberships to neighboring multicast routers. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility, and aims to become a guideline for query and other timers tuning. This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and act as PIM-SM routers. The proposed protocol extension addresses the tunnel convergence problem and provides seamless handover. This document defines the Proxy Binding Update and the Proxy Binding Acknowledgement messages with multicast extension. This document defines an RTCP XR Report Block and associated SDP parameters that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. Application-layer or overlay routing has been applied to various distributed systems such as content delivery networks and live media streaming systems. The problems with these systems for the layer 3 network providers, such as Internet service providers, are that these systems utilize higher-cost network resources (e.g., transit links) from the viewpoint of the layer 3 network providers but the operators have difficulties in controlling and optimizing the traffic of these systems because these systems construct their own networks over the layer 3 network. The ALTO Working Group has worked on application- layer traffic optimization to fill the gaps in routing policies between the layer 3 network and applications by providing the underlay network topology and cost information to these systems. However, there are considerations on applying application-layer traffic optimization techniques to cross-domain traffic because the cost is assumed to be configured by each AS although ASes are autonomously operated. This document summarizes general problems with overlay networks and considerations on the AS-level application- layer traffic optimization from the viewpoint of inter-AS economics. The main concerns on the AS-level application-layer traffic optimization are unfair policy configuration between distinct administrative domains and asymmetric economic policies on transit links. The underlying problem inducing these concerns is that the economic policies between interconnected ASes are non-disclosure due to commercial contracts. This document also discusses the conceivable approaches to solve the problems and considerations. In any BGP based MPLS network such as MPLS VPN [RFC4364], an ingress PE router would continue to attract traffic from the CE router by advertising the prefix reachability, even though the Label Switched Path (LSP) from the ingress PE router to the egress PE router may be broken. This causes the VPN traffic to be dropped inside the MPLS VPN network. This document proposes a framework to make BGP consider the MPLS path availability to the "NEXT_HOP" (i.e. egress PE router) during the BGP bestpath candidate selection process. This document also defines a local database for storing the MPLS path health information for one or more IP prefixes and its interaction with BGP. An operational forwarding device may need to be re-started (automatically or manually) for a variety of reasons, an event that we call a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to begin forwarding packets again. This document specifies a methodology for characterizing reset during benchmarking of forwarding devices, and provides clarity and consistency in reset test procedures beyond what's specified in RFC2544. It therefore updates RFC2544. This document defines a Dynamic Host Configuration Protocol (DHCP) Relay Agent Configuration option and associated machinery to configure the Relay Agent. This document specifies the value for the Time-to-Live in an IP packet that is destined to a link-local scope IP multicast address. These guidelines may be used for verification purposes. FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes one signaling protocol to determine and communicate the Configuration information between sender(s) and receiver(s). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. These include session establishment when LDP-IGP sync is in use and session re-establishment following loss of an LDP session when LDP graceful restart is in use. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). This document augments the Internet Assigned Numbers Authority (IANA) considerations for the Label Distribution Protocol (LDP), for protocol fields that are Reserved in the LDP Specification but for which there are no IANA allocation policies. This document specifies a mechanism to avoid blackholing of IP Multicast traffic due to the disruption of multicast tree during the time when the RPF neighbor is yet to become the PIM neighbor. Such scenario is possible during the topology change (e.g. link UP) in an IP network that employs PIM-SM (or SSM) as the multicast routing protocol and a unicast routing protocol (including static routing). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. It is a common practice to install a (soft or hard) loopback on a circuit interface for various purposes (e.g. circuit turn-up test). However, this practice results in disabling IPv6 on an interface even after the loopback is removed, due to the way IPv6 duplicate address detection is performed. This document describes a mechanism to allow IPv6 to self-heal after such a loopback is placed & removed. Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP). We consider using MPLS to route ECRTP compressed packets over an MPLS LSP without compression/decompression cycles at each router. Such an ECRTP over MPLS capability can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use header compression at each router. In this draft we propose to use RSVP-TE extensions to signal the header compression context and other control messages between the ingress and egress LSR. We re-use the methods in ECRTP to determine the context. VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS Labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. This document presents a generic connection admission control (GCAC) reference model and algorithm for IP/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for example, to reject voice over Internet Protocol (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE, NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective QoS for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that MPLS GCAC via elements along the selected path will in fact admit the request. In some cases (e.g., multiple AS) this objective cannot always be met, but the document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. This draft describes a proof-of-concept example of NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. The example is based on standardization work in the ITU-T of QoS signaling requirements. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. Together with the NSIS Transport Layer Protocol (NTLP), the NSLP provides functionality similar to RSVP and extends it. This draft provides a proof-of-concept example of the NSIS NSLP for QoS signaling. The example is based on standardization work in the ITU-T on QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in terms of the QoS-signaling model and Qspec template given in the 'NSLP for QoS Signaling' specification [QoS-SIG]. This draft describes a QSpec template for the QoS NSIS Signaling Layer Protocol (QoS NSLP) for signaling QoS reservations in the Internet. A QSpec is transported in QoS-NSLP messages and is opaque to QoS NSLP. It contains the QoS Signaling Model (QSM) Control Information and QoS Description parameters. Control Information is, for example, the scope of a particular QSpec. QoS Description parameters are primary input and output parameters of the Resource Management Function. They include descriptions of the QoS desired and the QoS reserved. QoS Description parameters can also be used for collecting information about resource availability along the path and for signaling a range of acceptable QoS. The QSpec template defines generic parameters that are common to many QSMs. Particularly they are derived from the IntServ and DiffServ QoS Models. They should be used by all QSMs if applicable and must be understood by all QNEs. By identifying the generic parameters we aim to ensure interoperability between different QSMs. This draft describes a mechanism to map QoS requirements from the User application layer down to the user plane to create an NSIS session. This 'vertical signaling interface' between the user application layer and user plane is needed to communicate these QoS requirements, such as bandwidth, flow priority values, etc. to user plane network elements. This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM control processing guidelines. This draft describes a QoS-NSLP signaling policy based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QSP extensions include additional QSPEC parameters and QSP control processing guidelines. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layers networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. Constraint-based path computation is a fundamental building block for traffic engineering systems such as multiprotocol label switching (MPLS) and generalized multiprotocol label switching (GMPLS) networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. There are multiple components in the Path Computation Element (PCE)- based path computation model, including PCE discovery and the PCE communication protocol. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to PCEs. This document specifies generic requirements for a communication protocol between PCCs and PCEs, and between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. Constraint-based path computation is a fundamental building block for traffic engineering systems such as MPLS and GMPLS networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the communication protocol requirements for a Path Computation Element (PCE)-based model. This document provides a problem statement for the proposed Path Computation Element (PCE). The PCE is an approach to MPLS traffic engineering path computation that is particularly applicable in inter-domain environments. In this context, a domain may be an IGP area, an Autonomous System, or some other division of computational responsibility. An overview of solution alternatives and proposed PCE work group charter is also provided. SUBSCRIBE, NOTIFY and PUBLISH methods in SIP are responsible for carrying presence information to a target destination. Message headers (Request-line, To, From, Contact etc.) indicate SIP entities that are identified by a URI. This document clarifies the indication of the message headers and provides a guideline on URI usage in the header fields. The authors hope that this document will be useful for SIP/SIMPLE implementers, interoperability testers, designers, and protocol researchers. As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. This draft describes requirements for connecting a pure photonic sub-domain to a GMPLS-based Label Switch Router. One of the main requirements is to avoid advertising all the physical properties of the underlying optical hardware while still peering with standard GMPLS. This draft discusses the requirements for abstracting the optical topology and the implications of various abstract models. This draft discusses possible extensions to [OSPF-TE] [GMPLS- Routing] and [ISIS-TE] for use by GMPLS networks that require additional constraints to be considered in the computation of viable paths. Continuity Check (CC), Proactive Connectivity Verification (CV) and Remote Defect Indication (RDI) functionalities required for are MPLS- TP OAM. Continuity Check monitors the integrity of the continuity of the path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the path between sink and source for any connectivity issues. RDI enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP or Section. This document specifies methods for proactive CV, CC, and RDI for MPLS-TP Label Switched Path (LSP), PWs and Sections using Bidirectional Forwarding Detection (BFD). This document considers a mobile terminal with multiple interfaces which uses Mobile IPv6[1]. With multiple interfaces, the mobile terminal may use them simultaneously for communication with a peer device. Hence enabling the mobile terminal to achieve fault tolerance, load balancing and so on. This document deals with the mobile terminal with multiple interfaces, so it is possible that each kind/type of interface may have its own characteristics or differences. In particular, we take a closer look at the path between mobile terminal and its home agent. In the case when the mobile terminal has multiple interfaces, there exists several paths to the home agent. A general approach would be to first take a look at effective use of the multiple interfaces from a pure Mobile IPv6 perspective. As a matter of course, RFC3775 is used as the basic reference with which we consider the multiple interfaced mobile terminal operating in a Mobile IPv6 environment. Diameter transport mechanism relies on storing data about received requests to detect duplicate requests. This document discusses the problems associated with this approach and defines new procedures to improve the efficiency of duplicate detection mechanism. Diameter base protocol defines the network layer functionality to be used by applications. This document adds hop-to-hop congestion notification mechanism to that functionality. Diameter transport mechanism relies on storing data about received requests to detect duplicate requests. This document discusses implementation and deployment considerations regarding this functionality. This document discusses parameters to consider, different approaches and design strategies to synchronize and/or recover state in Diameter applications after failure of an active instance. This document provides some considerations regarding the deployment of M3UA protocol, which were originally brought up at the SIGTRAN mailing list. Certain parts of the discussions in this document are applicable to other SIGTRAN protocols as well. This document defines M3UA IPSP procedures. It is based on IPSP concepts and procedures defined by M3UA specification. Its purpose is to describe M3UA IPSP procedures in an easy-to-follow single document and to provide clarifications for M3UA IPSP procedures. This document describes a protocol to support the communication between M3UA SGs in IP domain. The functionality needed by SGs to act as relay points between SS7 nodes is also addressed. Today, the use of anycasting is quite limited. In this document we list possible deployment scenarios in IPv6 anycasting. We consider three conditions based on the region of anycasting, and list possible scenarios. For each scenario we also clarify example applications as well as technical issues to be resolved. Today, the use of anycasting is quite limited. In this document we explain a new network architecture for global anycasting to solve (1) in practical use and able to realize with existing technology easily, (2) about support for stateful communications keeping a session information at the end nodes such as TCP. The architecture is based on MIPv6 because there are many similarities between MIPv6 and global anycast. This document describes the applications and characteristics of Anycast, which is network addressing and routing scheme that routes data through the best destination. The primary purpose of this document is to describe the many advantages and applications of Anycast and hopefully, to motivate you to consider new applications of Anycast. Since the route of packets to the same anycast adddress may change according to the network/node condition, it is not suitable to use anycast addresses directry for stateful communications (such as TCP). The more preferable use of the anycast addresses is to discover (the unicast address of) service node. The approach intended to describe in this document is to resolve (i.e., obtain) the corresponding unicast address for the anycast address prior to establishing the communication. We call this process as Anycast Address Resolving (AARP). The objevtive of the AARP is to enable the use of anycast addresses to all existing applications without any modifications. This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. The NETwork CONFiguration (NETCONF) protocol has been designed to configure routers, switches, firewalls and other network devices. This document describes a high level description of the Netconf architecture and how the Netconf framework relates to other network management protocols and architectures. The NETwork CONFiguration (NETCONF) protocol has been designed to configure routers, switches, firewalls and other network devices. This document describes a high level description of the Netconf architecture and how the Netconf framework relates to other network management protocols and architectures. This document specifies a binary format container for multimedia elements with embedded time synchronization information. This syntax is called Compact Media Format (CMF) and can be employed to create a multimedia presentation with sound, music, picture, animation, etc. in messaging and other applications. CMF is optimized for small size and efficient use in 3G wireless networks and is currently deployed in cdma2000(r) networks. The specification fulfills the requirement from Third Generation Partnership Project 2 (3GPP2) by registering a Uniform Resource Name (URN) namespace for the device identity and a sub namespace for the Mobile Equipment Identity (MEID). The structure of the MEID is 15 hexadecimal encoded digits long and is defined in 3GPP2 to uniquely identify a mobile equipment. This document defines an extended SMTP response for mail servers to assist clients in adjusting the rate at which they send mail. Use of this mechanism can reduce wasteful SMTP connections and reduce mail delivery delays; at scale the aggregate benefit to clients and servers can be significant. When e-mail is handed off today from one organization to another, as a rule no authentication of the sender of the e-mail or the computers delivering it on the sender’s behalf takes place. There are some simple steps which can be taken to significantly alleviate this problem, steps which mimic within the e-mail infrastructure the caller ID mechanism found in today’s telephone system. This proposal specifies that in addition to today’s practice of publishing in DNS the addresses of their incoming mail servers, administrators of domains also publish the addresses of their outgoing mail servers, the addresses of the computers from which mail legitimately originating from that domain will be sent. This information will then be used in enhancements to software that receives incoming mail to verify that computers handing off a message to them in fact are authorized to do so by the legitimate administrator of the domain from which the message is purported to have been sent. This document proposes several changes to the Internet standards process, especially a reduction from three to two stages in the IETF standards track. This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence. This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate next-hop is said to be a loop-free alternate, which goes to a neighbor whose shortest path to the prefix does not go back through the router S. This document defines and describes the use of U-turn alternates to provide local protection for IP unicast and/or LDP traffic in the event of a single failure, whether link, node or shared risk link group (SRLG). When a topology change occurs, a router S pre-computes for each prefix an alternate next-hop that can be used if the primary next-hop fails. An acceptable alternate can be either a loop-free alternate or a U-turn alternate. A U-turn alternate uses a neighbor, whose primary next-hop to the prefix is router S itself and which has itself a loop-free node-protecting alternate, which thus does not go through router S to reach the destination prefix. This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate can be either a loop-free alternate, which goes to a neighbor whose shortest path to the prefix does not go back through the router S, or a U-turn alternate, which goes to a neighbor whose primary next-hop to the prefix is the router S, and which has itself a loop-free node-protecting alternate, which thus does not go through router S to reach the destination prefix. In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link SLAs and non- RSVP TE traffic load. This specification uses IGP extension data (which is defined outside the scope of this document) to perform such path selections. This document proposes an extension to OSPF Version 2 for advertising link capabilities using the extensions defined for traffic engineering. The link capabilities are defined there for future extensibility. To support the signaling requirements of U-turn alternates for IP Fast-Reroute, this document defines three bits in the proposed link capabilities extension. This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects relevant for IP routes using IP Fast-Reroute [IPFRR]. As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. RFC 1112 offers no facilities for participant control or accounting. This document explores the requirements for such facilities, and offers a potential solution, based on extending the IGMP and MLD "join" operations to carry EAP and/or ERP packets. This document proposes some additions to the specification of the Protocol Independent Multicast - Sparse Mode (PIM-SM) Protocol regarding security issues of its link-local messages. Although the new specifications for IPsec architecture (RFC 4301) and Authorization Header (RFC 4302) permit the use of anti-replay, they counsel against its use for multi-sender, multicast Security Associations. This makes PIM-SM vulnerable to Denial of Service (DoS) attack. In this document, a new proposal is presented to protect PIM link-local messages while activating the anti-replay mechanism as well. This proposal builds on the new Security Association lookup method that has been specified in RFC 4301 and RFC 4302. This document defines basic terminology for describing different types of behavior for NATs and firewalls. It also defines a set of requirements for NATs and firewalls that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs and firewalls that meet this set of requirements will greatly increase the likelihood that applications will function properly. This document updates RFC3261 by providing clarifications, guidelines and new requirements concerning the use of SIPS URI Scheme in the Session Initiation Protocol (SIP). Feature referral allows for an application to make a high level request to a User Agent to perform an action or "feature", and let the the User Agent actually execute the feature as it sees fit. Feature referral uses the SIP REFER method with a Refer-To header field containing a URN. This document defines the Forces-IPTML protocol that is designed to complement ForCES-PL (ForCES Protocol Layer) for communicating between Forwarding and Control Elements that make up a ForCEs-compliant network element, using IP transport technology (e.g. TCP/IP, SCTP/IP, UDP/IP). This protocol addresses all the requirements described in the Forces [0] requirements document. This document also specifies architectural attributes necessary in an implementation of Forces-IPTML to ensure correct and secure protocol operation. This document defines the Forces-PL protocol that is designed for communicating between Forwarding and Control Elements that make up a ForCEs-compliant network element. This protocol addresses all the requirements described in the Forces [FORCES-REQ] requirements document. This document also specifies architectural attributes necessary in an implementation of Forces-PL to ensure correct and secure protocol operation. The main intent of this document is to define a Media Gateway Control Protocol (MGCP) package to control the reporting of metrics supported by the VoIP metrics block in RTCP Extended Reports as specified in [RFC 3611]. It also allows the call agent to control whether or not the gateway will request a peer device via SDP to send the VoIP metrics block in RTCP Extended Reports and whether it will respond positively to such requests from the peer device. Besides this primary focus, this package also allows the reporting of metrics defined for RTCP Sender Reports and Receiver Reports [RFC 3550] and the reporting of session description parameters (based on the ones defined in RFC 2327, RFC 2198 etc.). With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which actually responded is to have the name server include this information in the response itself. This note proposes a protocol extension to support this functionality. GSS-TSIG is not implementable as specified due to an omission, and the specification contains an unnecessary restriction. This note proposes a fix to both of these problems. 3GPP is defining the protocol specification for the Communication Barring (CB) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service and more particularly the dynamic incoming communication barring service. As part of dynamic incoming communication barring (ICB) service, a SIP based Event package framework is used for notifying users about communication barrings (dynamic and rule based) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the ICB supplementary service in IMS and may not be applicable to the general internet.. 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service. As part of CDIV, a SIP based Event package framework is used for notifying users about diversions (re-directions or forwarding) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. . This specification defines the new MODIFY method for the Real Time Streaming Protocol (RTSP). MODIFY method allows a RTSP client to indicate to the RTSP server to modify a particular session. Using MODIFY method, a client can indicate to either transfer or share a particular streaming session with other RTSP device. 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet. The 3GPP, as part of the MITE work item, is defining the Multimedia Telephony service and other Supplementary services using the IP Multimedia Core Network framework. Supplementary services include Incoming and Outgoing Communication Barring. This document describes a new set of procedures for Incoming Communication Barring to allow terminating users to dynamically block unwanted incoming communications. A new extension to SIP reason header is also described. The described in this memo protocol was developed for the application in distributed information measurement systems (IMS) at any stage of communication. It was designed for transmission of measured data from measuring devices to processing and storing equipment. Also it does support common device identification in distributed IMS. Due to its simplicity it can be easily implemented in firmware of any digital measuring device. This document describes the use of the Camellia block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). In many flavors of the nowadays address translators, real addresses are assigned to private hosts without preserving uniqueness; the same real address can be shared among multiple private hosts and the same private host can also obtain different addresses over the time as well. As a result the addresses used for private hosts reflect some kind of ambiguity on those hosts. This proposal introduces the IDNAT model as a solution for that address ambiguity problem. This solution concentrates on defining another virtual identity to identify private hosts in replacement of the ambiguous assigned real IP address. Through agile practices this identity can be assigned to each of the private hosts, and the hosts themselves will be aware of their assigned Ids which are going to be quite unique throughout the private region as well as the entire Internet realm. Moreover, the new Id will play a centric role in the packets transmission so as to identify the private host outside the private region and hence defeating the undesired ambiguity. RFC 3484 defines two algorithms for default source and destination address selection, but it has several shortcomings. This document specifies an alternate address selection algorithm that uses routing tables as policy input. This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas and GMPLS overlay networks. In certain scenarios, there may be a need to combine together two different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to-end (e2e) LSP is achieved and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. It might be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. TCP relies in communication peers to implement congestion control by hosts voluntary limiting their own data rate. Nevertheless this assumption introduces unsolved DoS attack opportunities. A DoS attack can be easily performed by a host that acknowledges TCP segments not yet received (maybe even not sent). This document presents and briefly describes the problem, already identified and pointed before, but also shows than it can be easily performed (with very interesting results) and proposes some server-side modifications to TCP stack in order to make this attack more difficult to perform. These modifications do nor cause interoperability issues. TCP relies in communication peers to implement congestion control by hosts voluntary limiting their own data rate. Nevertheless this assumption introduces unsolved DoS attack opportunities. A DoS attack can be easily performed by a host that acknowledges TCP segments not yet received (maybe even not sent). This document presents and briefly describes the problem, already identified and pointed before, but also shows than it can be easily performed (with very interesting results) and proposes some server-side modifications to TCP stack in order to make this attack more dificult to perform. When a private network or internetwork grows very large it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document discusses strategies for assigning and aggregating IPv6 address space. While CIDR was created to help alleviate this problem in regards to IPv4 addresses with the original [RFC1519] (and updated in [RFC4632]) we are now in need of a similar document to give direction for IPv6 addressing policies. Similarly, [RFC1518] discussed how to use CIDR to allocate address space for IPv4, and [RFC1887] discusses the subject for IPv6. The objective here is to update these documents and provide the best current guidance on how to manage address space in conjunction with managing the growth of routing tables in an IPv6 world. This document presents a scalable architecture for assigning and aggregating IPv6 address space. The current IPv4 assignment and addressing architecture has been successful in helping to scale the IPv4 routing architecture. This same architecture, when carried forward to IPv6, will help to ensure that the IPv6 routing architecture is sustainable. This document describes the requirements for access control mechanisms in the Domain Name System (DNS), which authenticate clients and then allow or deny access to resource records in the zone according to the access control list (ACL). This document proposes a mechanism for admission control and flow termination. It is based on the concept of pre-congestion notification (PCN) using three different codepoints: "no pre- congestion", "admission-stop", and "excess-traffic" for packet marking. Therefore, the proposal is called three state marking (3sm). The behaviour of edge nodes is presented which distinguishes from other proposals through little complexity and its ability to cope with multipath routing. Algorithms required for packet metering and marking are explained in detail. This document describes the simulation setups and results for testing the Three State PCN Marking approach. Simulations done to date, demonstrate that the three state PCN marking approach has certain ability to support admission control and flow termination of real- time application flows at the congestion point(s) of the PCN-enabled network. The real-time traffic used in the simulation covers voice and video traffic with large and small numbers of flows. This framework defines a method of providing Explicit Congestion Control to real-time inelastic traffic like voice and video through the use of session admission control and preemption mechanisms. This approach uses the Pre-Congestion Notification Marking (PCN) [1] mechanism. PCN marking is deployed in routers to measure and convey two levels of onset of congestion with the SIP controlled endpoints responding to the marking. This approach is different from what is defined in An edge-to-edge Deployment Model for Pre-Congestion Notification [3], as here the admission and preemption control function resides in the application (either in the endpoint or the application server that controls the endpoint. This framework is focused on using Session Initiated Protocol (SIP) as the application signaling protocol but other application signaling protocols could be extended for this purpose. At the 62nd IETF meeting, it was requested that the authors of Congestion Notification Process for Real-Time Traffic (RT-ECN) draft look at rate proportional marking as an method of indicating that traffic has exceeded a configured rate. In version 03 of RT-ECN draft (draft-babiarz-tsvwg-rtecn-03) we stated, when the rate exceeds the engineered traffic level, all packets as indicated by a DS codepoint from ECN-capable end-systems are marked to indicate congestion for the duration of the experienced congestion. In this memo, we looked at the two approaches, provide analysis as well our conclusions. This document specifies the usage of Explicit Congestion Notification (ECN) markings for real-time inelastic flows such as voice, video conferencing, and multimedia streaming. We build on the principles of RFC 3168, "The Addition of Explicit Congestion Notification to IP", and apply them to real-time inelastic traffic in DiffServ networks. Defined in this document are, new ECN semantics that provide two levels of experienced congestion along the path for real- time inelastic flows, the required ECN marking behavior in network nodes, and state the required behavior of end-systems that support this function with an explanation of how the two ECN schemes can co- exist safely in the network. [RFC4588] documents two methods to multiplex RTP sessions: session- multiplexing and SSRC-multiplexing. This document specifies the SSRC-multiplexing for RTP sessions. Typically an NAV (network-based anti-virus) system stores the entire HTTP response from the server, scan the response for malware and then transmits it to the client. This extension attempts to better response time for Web traffic by letting the NAV (network-based anti-virus) system save the time required for the NAV system for transmission of data from the NAV system to the client. In addition, this extension also helps in reporting download progress and avoiding client connection timeout. Intercepting transparent proxies splice the client-Server connection into two connections: Client-Proxy connection, Proxy-server connection. On Client-Proxy connection, proxy sends it's certificate to the client. As client is generally (in such a scenario) pre-configured to accept proxy's certificate, client accepts and proceeds further with the connection. On Proxy-Server connection, server sends its certificate to the proxy. Proxy typically doesn't possess the information (like MX domain name in case of SMTP) required to validate the certificate. The certificate validation is at times very complex & hence it is better to offload this reponsibility to the original client itself. This document addresses this issue by extending TLS to let proxy send server's certificate to the client for validation and suggests how client can indicate certificate validation result to the proxy. This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. This document describes some characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. This document describes some characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, enhanced with MANET techniques based on multi-point relaying (MPR). This document describes an NSIS QoS Signaling Policy model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control to Differentiated Services (Diffserv) networks. RMD complements the Diffserv architecture by pushing complex classification, conditioning and admission control functions to the edges of a Diffserv domain and simplifying the operation of internal nodes. This draft describes a local QoS model, denoted as Resource Management in Diffserv (RMD) QoS model, for NSIS that extends the IETF Differentiated Services (Diffserv) architecture with a scalable admission control and resource reservation concept. The specification of this QoS model includes a description of its QoS parameter information, as well as how that information should be treated or interpreted in the network. This draft specifies CEQMM, a Complete and Efficient Quality of Service (QoS) Model for MANETs which combines the positive aspects of both IntServ and DiffServ. It uses a hybrid per-flow and per-class provisioning scheme. In such a scheme, traffic of highest priority is given per-flow provisioning while other priority classes are given per-class provisioning. To offer this scheme and to ensure that certain packets receive higher priority transmission than other packets, priority classifier, active queue management and packet scheduler are integrated. CEQMM applies the QOLSR protocol to support multiple-metric routing criteria and to respond quickly when changes in topology and/or QoS conditions are detected. Once a path is chosen for one QoS flow, CEQMM performs call admission control (CAC) at each intermediate node. For only QoS flows of highest priority, a node can precede to soft and later hard bandwidth reservation on links during the CAC process. CEQMM implements congestion avoidance mechanisms to prevent a network from entering the congested state. However, in MANETs, network congestion can still occur frequently under mobility. In order to prevent performance degradation due to mobility-triggered congestion, CEQMM uses congestion control scheme based on: (i) rated control of best-effort traffic, (ii) path selection for best-effort traffic, (iii) next hop maintaining for each QoS class (except the high-priority class), (iv) active queue management and (v) backoff timer method. The Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks provides shortest routes in terms of number of hops using Dijkstra's shortest path algorithm. In order to support multiple- metric routing criteria, a quality of service (QoS) extension can be added to OLSR functioning. No additional control traffic is generated (only augmented HELLO and TC messages). QOLSR protocol uses standard multipoint relays (MPRs) to ensure that the overhead is as low as possible for forwarding control traffic. Local QoS metrics information on links are used to calculate quality of service MPRs (QMPRS) and then flooded in the network by TC messages to calculate routing tables. QOLSR can find optimal paths on the known partial topology having the same performances that those on the whole network. These paths contain only QMPRs as intermediate nodes between a source destination pair. This memo describes the QOLSR protocol, which is an enhancement of OLSR to support multiple-metric QoS routing. EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a full TLS handshake is used to mutually authenticate a peer and server and to share a secret key. EAP-Double-TLS extends this authentication negotiation by establishing a secure connection based on the use of Pre Shared Keys (PSK). The secure connection may then be used to allow the server and the peer to securely exchange their identity and to update security attributes for next sessions. EAP-Double-TLS allows the peer and the server to establish keying material for use in the data connection between the peer and the authenticator. The keying material is established implicitly between peer and server based on the TLS Pre-Shared-Key handshake. Actual EAP methods provide authentication services based on the use of certificates, secret keys or passwords. These methods, excepting the tunneling ones, exchange peer identity in clear text. Moreover, some of these methods do not enable the ability to exchange channel binding information. They do not, however, define a common encoding of the credential protection or of the channel binding or of. This document defines AVPs to securely exchange data related to the peer identity, when an EAP method deriving keys is deployed. This document extends RFC 4279 and RFC 4785 and specifies a set of ciphersuites that use an Elliptic Curve Diffie-Hellman exchange authenticated with a pre-shared key. These ciphersuites provide Perfect Forward Secrecy. It also specifies one authentication-only ciphersuites (with no encryption). This ciphersuite is useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. The (Datagram) Transport Layer Security ((D)TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex several application data over a single (D)TLS. This document defines MTLS, an application-level protocol running over (D)TLS Record protocol. The MTLS design provides application multiplexing over a single (D)TLS session. Therefore, instead of associating a (D)TLS session with each application, MTLS allows several applications to protect their exchanges over a single (D)TLS session. The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. 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. This document defines a special Signaling Cipher Suite Value (SCSV) "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to the TLS protocol. This document specifies new key exchange methods for Transport Layer Security protocol to support authentication based on pre installed key and to allow anonymous exchanges, identity protection And Perfect Forward Secrecy. The Transport Layer Security (TLS) is the most widely deployed protocol for securing network traffic. It provides mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex single-application multiple-stream applications that commonly use parallel connections to the same logical and/or physical server application data. This document describes a mechanism to multiplex single-application multiple-stream over TLS. It extends TLS to multiplex parallel conn