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 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. 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 HTTP Cookie and Set-Cookie headers. NOTE: Much of the text herein is completely wrong. 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 headers 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 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. This document defines the HTTP Origin header. The Origin header is added by the user agent to describe the security contexts that caused the user agent to initiate an HTTP request. HTTP servers can use the Origin header to mitigate against Cross-Site Request Forgery (CSRF) vulnerabilities. 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 both static provisioning of transport paths via an NMS/OSS, and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane signaling, routing, addressing, traffic engineering, path computation, and recovery in the event of network failures. The document focuses on the control of Label Switched Paths (LSPs) as the Pseudowire (PW) control plane is not modified by MPLS-TP. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. Backwards compatibility to MPLS is required. Management plane functions such as manual configuration, 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. 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 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. 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. 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 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 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. 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. 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 specifies a common interface for using HIP with a Distributed Hash Table service to provide an unmanaged 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. 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. 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. 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". 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 issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], 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. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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. 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. 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. 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 deprecates 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 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. 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). 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 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 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). 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. 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 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. 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. 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. 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. 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. 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 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 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 tries to speculate 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 mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. 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 essential points to be modified 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. 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. 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 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 document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. 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 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 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. 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 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) [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 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. The optimization includes a query timer tuning and an explicit membership notification operation. 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. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. 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. 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. 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. 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 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. 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 are MPLS-TP OAM requirements listed in [3]. 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. It is RECOMMENDED that a protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs and Sections as per [3]. 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. 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 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 for 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. 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]. 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 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. 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 as specified in RFC 5220. RFC 5221 lists some requirements for any attempts to update the original RFC. This document specifies an alternate address selection algorithm to fulfill those requirements. 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 it using private IPv4 address space. 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. 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. 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 important 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. 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 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 connections of a given application over a single TLS session, avoiding additional delay related to the TLS/TCP session/connection setup. The NETCONF configuration protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use TLS to secure NETCONF exchanges. This document specifies a new Transport Layer Security (TLS) extension and a new TLS message providing TLS client authentication using passwords. It provides client credential protection. This document specifies a set of new ciphersuites for the Transport Layer Security (TLS) protocol to support TLS client authentication based on passwords. These ciphersuites provide client credential protection. RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of cipher suites for TLS/DTLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). This document describes a nested NEMO Route Opimization (NNRO) protocol for the communications between any two nodes in the same nested mobile network. A nested NEMO Route Opimization message is used to exchange the routing information between two mobile network nodes in the same nested mobile network. The protocol is designed in a way such that the mobility of the entire nested mobile network is transparent to the nodes therein. This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client- server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with NAT64. NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64, and gives suggestions on how they should be deployed. This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. This document performs a preliminary threat analysis on the Locator/ID Separation Protocol (LISP) as defined in draft-farinacci-lisp-01.txt. Multi-addresses/Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that each endpoint of a given TCP connection can use multiple IP addresses to exchange data (instead of a single IP address per endpoint as currently defined). Such extensions enable the exchange if segments using different source- destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. In particular, some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP. RFC 3178 [1] describes a solution to provide site multi-homing support in IPv6. RFC 3178 multi-homing solution uses tunnels between the different ISPs and the multi-homed site to provide alternative paths in case that one of the exit links is down, protecting the multi-homed site from outages in the direct link with its providers. However, the wide adoption of RFC 3178 multi-homing solution implies the manual configuration of numerous tunnels on the ISPs, which may impose an important workload in ISP network administrators. This note proposes the usage of Multi-Homing Tunnel Brokers to automatically configure the ISP tunnel endpoint in order to ease the adoption of the solution. In this note we will present a functional decomposition of the M6 protocol i.e. the protocol for preserving established communications in multihomed environments. We will do so by describing a protocol walkthrough, presenting which functions have to be performed at each stage and the messages required to accomplish them. The functional decomposition presented in this draft is based on the general functional analysis of multihoming approaches presented in [3]. This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. The main idea is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by appending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. The goal of this note is to analyze the possible application of a multi6 protocol to provide nemo multihoming support. We will first state the basic assumptions behind a multi6 protocol design and then we will analyze each of the multihoming configurations for nemo described in [1] in order to determine if the multi6 can provide the support required. This draft discusses extensions to the shim6 architecture to support shim6 proxies that would allow the provision of the following capabilities: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. o Enable legacy IPv6 nodes located in the multihomed site to obtain full multihoming support (no modification of the end nodes). This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. This memo describes FCFS SAVI a mechanism to provide source address validation for IPv4 and IPv6 networks using the First-Come First- Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. This memo describes SeND SAVI, a mechanism to provide source address validation using the SeND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. This note describes mechanisms for address selection in hosts within a multihomed site. The goal of these mechanisms is to allow hosts within the multihomed site to establish new communications after an outage. The presented mechanisms are not by themselves a complete multihoming solution but rather a component of such solution. This document define a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. The note presents a set of mechanisms to provide ingress filtering compatibility for legacy hosts in IPv6 multihomed sites. In this note, we explore the interaction between the SHIM protocol and MIPv6 protocol, identifying potential benefits and difficulties. The analysis will consider the two modes of operation of MIPv6: the Bidirectional Tunnel (BT) mode where the communication is routed through the Home Agent and the Route Optimization (RO) mode, where the communication flows directly between the Correspondent node and the mobile node. This note presents a privacy analysis for the SHIM6 protocol for IPv6 site multihoming support and the failure detection extensions for the SHIM6 protocol.This note does not attempt to provide a solution for providing SHIM6 protocol privacy. This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm. DNS records for the mail services POP3, POP3S, IMAP and IMAPS do not currently provide failover switching as do the DNS MX records for SMTP. This document looks at the issues involved and recommends a solution using SRV records. This document describes a binary encoding format for an arcband, which is compatible with the binary encoding defined by 3GPP [3GPP23.032], and which is widely used in today's cellular networks. This encoding can additionally be used by a number of other protocols, which demand a bandwidth efficient encoding of location information, eg link layers like IEEE 802.11. This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [RFC3775]. The herein defined RRT mechanism is intended for CoA exchanges between the MN and the CN. Once the MN and CN find out their peers' valid addresses, an additional mechanism, defined in [I-D.tschofenig-mip6-ice], will be used to run connectivity checks to figure out which of the address pairs have connectivity and, if needed, open the required pinholes in the firewalls as described in [4]. The defined mechanism is intended to work with current firewalls without requiring any support from them. This document defines a number of Dynamic Host Configuration Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a list of domain names or IP addresses that can be mapped to servers providing IEEE 802.21 type of Mobility Services. These Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [IEEE802.21]. This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide Mobility Services. Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [1]. 3GPP2 is working in specifying a way to allow the mobile network subscribers to configure the Firewalls in their network according to their needs[3]. This document defines requirements for a Firewall Configuration Protocol. It has been produced by a number of 3GPP2 member companies and endorsed by 3GPP2. It contains 3GPP2 requirements to a next generation Firewall Configuration Protocol. With the number of threats that keep increasing on the Internet, many networks have decided to deploy Firewalls to reduce the possible risks and protect their users as well as their network resources. Firewalls can however present many issues with new protocols, applications and scenarios to be supported. Data packets may be discarded at the Firewalls. In addition, the clients may often be the only parties that know the requirements and details of the data communications. This document therefore explains why a protocol allowing clients to configure Firewalls would be useful, and attempts to identify the requirements and features to be supported by such a protocol. When IPv6 was designed, the assumption was that the transition from IPv4 to IPv6 will occur way before the exhaustion of the available IPv4 address pool. The unexpected growth of the IPv4 Internet and the hesitation and technical difficulties to deploy IPv6 indicates that the transition may take much longer than originally anticipated. It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4 addresses. The Internet should reach a safety point in the future, where the number of IPv4 public addresses in use at a given time begins decreasing. It is very likely that the IPv4 public address pool currently available at IANA will be exhausted before the internet reaches this safety point. This creates a need to prolong the lifetime of the available IPv4 addresses. This document defines methods to allocate the same IPv4 address to multiple hosts, with the aim to prolong the availability of public IPv4 addresses, possibly for as long as it takes for IPv6 to take over the demand for IPv4. With the foreseen scarcity of public IPv4 addresses and the hesitation and technical difficulties to deploy IPv6, the transition scenarios which assumed that migration to IPv6 happens before the run-out of IPv4 addresses, need to be revisited. This document defines a method to allocate the same IPv4 address to multiple hosts, thus prolonging the availability of public IPv4 addresses for as long as it takes for IPv6 to take over the demand for IPv4. The document also describes the deployment scenarios where this method is applicable. This note addresses routing in a network that supports multiple prefixes and has different DMZs, in the context of BCPs 38 and 84 (ingress filtering). It proposes a change to the way IPv6 forwarding occurs, and so should be considered carefully by the Internet community. The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. This note proposes an address and service architecture designed to facilitate transition from an IPv4 Internet to an IPv6 Internet. This service contains three parts: A DNS Application Layer Gateway, a stateful Network Address Translator that enables IPv6 clients to initiate connections to IPv4 servers and peers, and a stateless Network Address Translator that enables IPv4 and IPv6 systems to interoperate freely. It is couched as an update to RFCs 2765 and 2766. This is because the stateless service is essentially the SIIT with a different address format, and because the DNS Application Layer Gateway and the stateful translator have significant similarities to NAT-PT. There are, however, important differences from NAT-PT, responsive to the issues raised in RFC 4966. This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment with neither state nor configuration in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport_port tuples and IPv6 address/ transport_port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Significant issues exist in the stateless and stateful modes that are not addressed in this document, related to the address assignment and the maintenance of the translation tables, respectively. This document confines itself to the actual translation. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage. 2. Moving the address format to the framework document, to coordinate with other drafts on the topic. 3. Description of both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references.Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. This paper summarizes the recommended correlation between service classes and their usage, with references to their corresponding recommended Differentiated Service Code Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB) and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioner PHBs and AQM be used for a certain service class, but as a policy it is useful that they be applied consistently across the network. This note attempts to identify the core of the Internet Protocol Suite. The target audience is NIST, in the Smart Grid discussion, as they have requested guidance on how to profile the Internet Protocol Suite. In general, that would mean selecting what they need from the picture presented here. This memo is to point out a security issue in IPv6 Neighbor Discovery. This memo considers the question of IPv6 prefix sub-delegation. This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. This document discusses the general problem of routing in an IPv6 Nested Virtual Private Network. A solution is proposed based on one- way hashes of IP Prefix values. The concepts extend to IPv4, but with difficulty due to the number of bits in question. As requested in the SAVA discussions, this document describes Cisco's IP Source Guard feature. This note describes how Source Address Validation might be applied in an IPv6 environment. Local systems should be able to ensure that their peers are using the IPv6 source addresses that the routing system uses to deliver data to them. Remote systems should be able to ensure that traffic they forward has reasonable source addresses. This note proposes a practical solution to Internet Layer Source Address Verification. The purpose of such verification is to prevent attacks from using spoofed addresses and to facilitate the tracking of attack datagrams to the computers that send them. This note proposes a simple solution to Source Address Validation, assuming that the purpose of such validation is to prevent attacks from using spoofed addresses. For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This document requests a DSCP from the IANA for a class of real-time traffic conforming to the Expedited Forwarding Per Hop Behavior and admitted using a CAC procedure involving authentication, authorization, and capacity admission, as compared to a class of real-time traffic conforming to the Expedited Forwarding Per Hop Behavior but not subject to capacity admission or subject to very coarse capacity admission. One of the reasons behind this is the need for classes of traffic that are handled under special policies, such as the non-preemptive Emergency Telecommunication Service, the US DoD's Assured Service (which is similar to MLPP), or e-911. These do not need separate DSCPs or separate PHBs that are separate from each other, but they need a traffic class from which they can deterministically obtain their service requirements from including SLA matters. The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are four documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol', and the 'Multi-Level Expedited Forwarding Per Hop Behavior' (MLEF PHB). MLEF, as currently defined, has serious problems, which this draft seeks to discuss. The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are three documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol'. Some networks require communication between an interior and exterior portion of a VPN, but have sensitivities about what information is communicated across the boundary. This note seeks to outline the issues and the nature of the proposed solutions. This note describes a network architecture for business-to-business private networking. It actually describes two: one for IPv4 and one for IPv6. This note is intended to describe the end to end problem as it applies to a network of networks, wherein some component networks independently run only IPv4 with or without a transition mechanism, some run only IPv6 with or without a transition mechanism and without coordination of transition mechanisms, and some run IPv4 and IPv6 in parallel supporting native routing. This note discusses a feature to support building Greynets for IPv4 and IPv6. This document presents IETF commentary to the Registry and ISP communities on how to maximize aggregation while supporting multihoming. Multihomed networks fall broadly into two categories, those that are in some senses comparable to an ISP and those that are simply edge networks or VPNs of edge networks. The best solution for multihoming may be different for these differing categories of networks. This document registers new disposition-types for the Content- Disposition header that apply to the application/3gpp-ims+xml body used by 3GPP, since Release 5. The applicability of these content- disposition values are limited to 3GPP IMS. The application/ 3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. This document provides guidelines for zone administrators(including but not limited to registry operators and registrars), and information for all domain names holders, on the administration of those domain names which contain characters drawn from Arabic Characters Group of Languages. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that is helpful. The document gives basic guidelines for IDN registrars (as it is the case for IETF Document that talks about Japanese, Chinese and Korean domain name registration "RFC 3490"). The document provides also information for owners of IDN that contains Arabic characters on name reservation process. The document does not cover Arabic gTLD or ccTLD problems. Comments on this document can be sent to the authors at arabic-idn-admin@aietf.org. Vehicular ad hoc Networks (VANETs), self-organized networks based on short-range wireless technologies, aim at improving road safety and providing comfort and entertainment applications. The Car2Car Communication Consortium is defining a European standard for inter- vehicle communication that adopts VANETs principles. This document specifies requirements for Route Optimization techniques for usage of Network Mobility (NEMO) in VANETs as identified by the Consortium. There is a requirement for service providers to be able to extend the reach of pseudo wires ( PW ) across multiple Public Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge Routers. Extensions to VPLS PE model to accommodate PBB components where discussed in [PBB-VPLS Model]. This draft discusses optional extensions to the LDP Signaling procedures in [RFC4762] required to further enhance the PBB-VPLS solution. IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. [MS PWE3 Requirements] describes the requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. The current specification of the PW Architecture [PW ARCH] defines the PW as a single Segment entity, connecting the Attachment Circuits between two Ultimate PEs (U-PE). The current procedures for establishing a single segment PW (SS-PW) is described in [PW Control], where typically an LDP session is established between the ultimate PEs handling the Pseudowire End Service (PWES). No intermediate nodes, between the PEs, are aware of the PW. The purpose of this draft is to specify new LDP extensions, end to end signaling procedures to address the related requirements specified in [MS-PWE3 Requirements]. The proposed procedures follow the guidelines defined in [RFC3036bis] and enable the usage of addressing schemes (L2FECs) and other TLVs already defined for PWs in [PW Control]. The solution described in the draft provides a MS-PW Operational Model, Signaling Procedures consistent with the regular (SS-)PWs, in order to enable seamless implementation, deployment. The resulting MS-PW building blocks accommodate and enhance LDP-VPLS, VPWS solutions with minimal changes in the Information Models and Software Modules related to the L2VPN functionality. This document proposes a PW encapsulation specific to IP packets, the IP Pseudowire, following the architectural principles defined in [PWE3 Architecture]. This proposal introduces an optional CW for IP encapsulation. Note that when the inclusion of a control word is not negotiated, the IP PW uses the encapsulation described in [RFC3032]. IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. The memo provides information and suggests processes for developers of applications based on the DNS protocol and for administrators of servers and networks. It suggests new procedures for DNS and DNSSEC implementations that would prevent abuse of the DNS protocol such as those seen by "Double Flux" service networks. Specifically, this document recommends that all resource records for NS records with Time-To-Live (TTL) settings under 24 hours be dropped as potentially malicious records designed to attack users. This document would update RFCs 1123, 1912, 2181 and 2535. This document describes the proper methods to use when replying to messages in a One to Many communication environment such as USENET, mailing lists, or bulletin boards. It is recommended that top-posting in a summary reply be used primarily, or if desired and appropriate that middle-posting or conversational-posting be used in a point-by-point reply. Pre-configured routing is a routing scheme that except primary route operator configures one or multiple routes which will be used as recovery route when the primary route fails for a service previously. This document improves this traditional routing shceme, and PCE (Paht Computation Element) is applied for pre-configured routing. Furthermore, this document also presents a detailed set of PCC-PCE (Path Computation Client) communication protocol requirements and defines PCEP (Path Computation Element Communication Protocol) extensions for PCEP. The Extensible Authentication Protocol (EAP) is a general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers without requiring IP. EAP can be used for different types of authentication, where multiple providers provide different services. However, EAP itself does not have the ability to differentiate between multiple EAP conversations between a peer and an authenticator. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. This document describes a RTP payload format for transporting Theora encoded video. It details the RTP encapsulation mechanism for raw Theora data and configuration headers necessary to configure the decoder. Also included within the document are the necessary details for the use of Theora with MIME and Session Description Protocol (SDP). This document provides an overview of SCS, a cryptographic protocol aimed at the protection of "client-side" HTTP sessions, i.e. sessions in which the application state is held entirely on the client in the form of cookies [10]. The use of Internet technologies for emergency calling creates opportunities for fraud, relative to traditional circuit-switched emergency calling. This document describes the context for IP-based emergency calling, and the types of fraud which are possible within the system. A mitigation strategy for fraud against voice service providers is described; techniques for detecting or preventing other types of fraud will be incorporated in this document as they are available. Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. Location-based services (such as navigation applications, emergency services, management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. However, these protocols lack a mechnism for the htarget host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. Protection of location information is an essential requirement of the GEOPRIV architecture. Since using protocols cannot be relied upon to provide adequate protections to the location objects they carry, the location objects themselves must be secured. This document examines several candidates for a Secure Location Object format in the context of GEOPRIV and ECRIT security requirements, including both locations by value and by reference. This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. This document describes the security model for the OAuth authorization system, which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other. In this document, we describe a set of design constraints, a high-level work flow for establishing authorizations subject to those constraints, and set of security requirements for protocols that implement this model. The base HTTP Enabled Location Delivery (HELD) protocol includes options for retrieving location information from a LIS by a Device. Some networks require the ability for the device to periodically request location information from the LIS and/or for the LIS to periodically request location information from the device. Extensions to base HELD allow a Device to establish a context with a LIS and negotiate capabilities of the Device in terms of providing location information. The measurement extensions to base HELD allow the LIS to request location information from a Device. This document provides an overview of the requirements and a solution using HELD and HELD extensions to support the periodic request of location information, both by a Device from an LIS and by the LIS from a Device, depending upon the specific scenario and measurement capabilities of the Device. The Session Initiation Protocol (SIP) enables and permits endpoints in an INVITE transaction to send media packets before an SDP offer/ answer exchange has completed; we refer to such media packets as early media. The use of early media is common in current SIP implementations, and causes several problems, which have been documented elsewhere. This document puts forward the goal of modifying SIP so that compliant implementations will complete an SDP exchange before sending media, and lays out high-level requirements for such a solution. The set of possible solutions is then laid out, and each possibility examined in light of these requirements. This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. This draft discusses a standard mechanism for securing information in SIP requests and responses, inserted by intermediaries, which may be used by other intermediaries or the endpoints as the basis for services. The requirements are based on the need for a general middle-to-middle and middle-to-end security mechanism applicable to both