| |
|
| |
| | 6LoWPAN Neighbor Discovery |
| |
| | draft-ietf-6lowpan-nd-07.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Carsten Bormann, Erik Nordmark |
| | Working Group: |
IPv6 over Low power WPAN (6lowpan) |
| | Formats: |
txt |
|
This document specifies an extension of Neighbor Discovery for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over energy and bandwidth constrained wireless networks often making use of multihop topologies. However, the use of classic IPv6 Neighbor Discovery with 6LoWPAN has several problems. Classic Neighbor Discovery was not designed for non-transitive wireless links, and the traditional IPv6 link concept and heavy use of multicast makes it unpractical. This document specifies an ND mechanism both sufficient for minimal for LoWPAN operation which optimizes Neighbor Discovery. |
| | RTP Payload Format for SVC Video |
| |
| | draft-ietf-avt-rtp-svc-20.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis |
| | Working Group: |
Audio/Video Transport (avt) |
| | Formats: |
txt |
|
This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. |
| | DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers |
| |
| | draft-ietf-behave-dns64-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum |
| | Working Group: |
Behavior Engineering for Hindrance Avoidance (behave) |
| | Formats: |
txt xml |
|
DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with 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 IPv6/IPv4 translators. |
| | IPv6 Addressing of IPv4/IPv6 Translators |
| |
| | draft-ietf-behave-address-format-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Christian Huitema, Congxiao Bao, Marcelo Bagnulo, Mohammed Boucadair, Xing Li |
| | Working Group: |
Behavior Engineering for Hindrance Avoidance (behave) |
| | Formats: |
txt xml |
|
This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. |
| | Call Completion for Session Initiation Protocol (SIP) |
| |
| | draft-ietf-bliss-call-completion-05.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev |
| | Working Group: |
Basic Level of Interoperability for SIP Services (bliss) |
| | Formats: |
txt |
|
The call completion features allow the calling user of a failed call to be notified when the called user becomes available to receive a call. For the realization of a basic solution without queueing call- completion requests, this document references the usage of the the dialog event package [RFC4235] as described as 'automatic redial' in [RFC5359]. For the realization of a more comprehensive solution with queueing call-completion requests, this document introduces an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. The deployment of a certain SIP call-completion solution is also dependent on the needed level of interoperability with existing call- completion solutions in other networks. |
| | Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) |
| |
|
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in 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 document discusses use cases, lists requirements and defines SIP extensions to implement this feature. |
| | Benchmarking Methodology for Link-State IGP Data Plane Route Convergence |
| |
|
This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The methodology can be applied to any link-state IGP, such as ISIS and OSPF. |
| | Terminology for Benchmarking Link-State IGP Data Plane Route Convergence |
| |
|
This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. |
| | Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS |
| |
|
This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. |
| | OAM Configuration Framework and Requirements for GMPLS RSVP-TE |
| |
|
OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. |
| | GMPLS RSVP-TE Extensions for Ethernet OAM Configuration |
| |
|
The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK]. |
| | Certificate profile and certificate management for SEND |
| |
|
SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on Resource Certificates along with extended key usage values required for SEND. |
| | DHCPv6 option for network boot |
| |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network. |
| | DHCPv4 Leasequery by relay agent remote ID |
| |
|
Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. |
| | Bulk DHCPv4 Lease Query |
| |
| | draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati |
| | Working Group: |
Dynamic Host Configuration (dhc) |
| | Formats: |
txt |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. |
| | Diameter Quality of Service Application |
| |
| | draft-ietf-dime-diameter-qos-13.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Dong Sun, Pete McCann, Hannes Tschofenig, Tina Tsou (Ting ZOU), Avri Doria, Glen Zorn |
| | Working Group: |
Diameter Maintenance and Extensions (dime) |
| | Formats: |
txt xml |
|
This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. |
| | Diameter NAT Control Application |
| |
| | draft-ietf-dime-nat-control-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Frank Brockners, Vaneeta Singh, Shwetha Bhandari, Victor Fajardo |
| | Working Group: |
Diameter Maintenance and Extensions (dime) |
| | Formats: |
txt |
|
This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. |
| | DomainKeys Identified Mail (DKIM) Development,Deployment and Operations |
| |
|
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. |
| | Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery |
| |
|
The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. |
| | Simple procedures for Detecting Network Attachment in IPv6 |
| |
|
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. |
| | DNS Transport over TCP |
| |
|
This document updates the requirements for the support of the TCP protocol for the transport of DNS traffic. |
| | Initializing a DNS Resolver with Priming Queries |
| |
|
This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. |
| | Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements |
| |
|
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. |
| | An Architecture for Location and Location Privacy in Internet Applications |
| |
| | draft-ietf-geopriv-arch-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Richard Barnes, Matt Lepinski, Alissa Cooper, John Morris, Hannes Tschofenig, Henning Schulzrinne |
| | Working Group: |
Geographic Location/Privacy (geopriv) |
| | Formats: |
txt |
|
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. |
| | Graceful BGP session shutdown |
| |
| | draft-ietf-grow-bgp-gshut-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Pierre Francois, Bruno Decraene, Cristel Pelsser, Clarence Filsfils |
| | Working Group: |
Global Routing Operations (grow) |
| | Formats: |
txt |
|
This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions. |
| | HIP Certificates |
| |
|
This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in HIP control packets. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and in SPKI certificates. |
| | HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment |
| |
| | draft-ietf-hip-bone-03.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, Ari Keranen, Alan Johnston |
| | Working Group: |
Host Identity Protocol (hip) |
| | Formats: |
txt |
|
This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. |
| | HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-layer Protocol Signaling (HICCUPS) |
| |
|
This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. |
| | Host Identity Protocol (HIP) Multi-hop Routing Extension |
| |
|
This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of hosts that forwarded it. |
| | Distribution of EAP based keys for handover and re-authentication |
| |
|
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK) or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. The document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using an AAA (Authentication, Authorization and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g. RADIUS or Diameter) before it can be used. |
| | HTTP/1.1,part 1: URIs,Connections,and Message Parsing |
| |
| | draft-ietf-httpbis-p1-messaging-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. |
| | HTTP/1.1,part 2: Message Semantics |
| |
| | draft-ietf-httpbis-p2-semantics-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields. |
| | HTTP/1.1,part 3: Message Payload and Content Negotiation |
| |
| | draft-ietf-httpbis-p3-payload-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. |
| | HTTP/1.1,part 4: Conditional Requests |
| |
| | draft-ietf-httpbis-p4-conditional-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. |
| | HTTP/1.1,part 5: Range Requests and Partial Responses |
| |
| | draft-ietf-httpbis-p5-range-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. |
| | HTTP/1.1,part 6: Caching |
| |
| | draft-ietf-httpbis-p6-cache-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. |
| | HTTP/1.1,part 7: Authentication |
| |
| | draft-ietf-httpbis-p7-auth-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. |
| | Internationalized Domain Names for Applications (IDNA): Background,Explanation,and Rationale |
| |
|
Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. |
| | Internationalized Domain Names in Applications (IDNA): Protocol |
| |
|
This document is the revised protocol definition for internationalized domain names (IDNs). The rationale for changes, the relationship to the older specification, and important |
| | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework |
| |
|
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. |
| | Generic Subtype for BGP Four-octet AS specific extended community |
| |
|
Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. |
| | Error Handling for Optional Transitive BGP Attributes |
| |
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes. |
| | Definitions of Managed Objects for IP Flow Information Export |
| |
| | draft-ietf-ipfix-mib-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Thomas Dietz, Atsushi Kobayashi, Benoit Claise, Gerhard Muenz |
| | Working Group: |
IP Flow Information Export (ipfix) |
| | Formats: |
txt |
|
This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. |
| | IPv6 Configuration in IKEv2 |
| |
|
When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". |
| | A Generalized Framework for Kerberos Pre-Authentication |
| |
|
Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secrets of the principal. This document describes a model for Kerberos pre-authentication mechanisms. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the KDC with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. |
| | Framework and Requirements for Virtual Private Multicast Service (VPMS) |
| |
|
This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. |
| | Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution |
| |
|
More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. |
| | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
| | draft-ietf-manet-nhdp-11.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Thomas Clausen, Christopher Dearlove, Justin Dean |
| | Working Group: |
Mobile Ad-hoc Networks (manet) |
| | Formats: |
txt |
|
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). |
| | Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to operators troubleshooting multicast forwarding problems. |
| | Mtrace Version 2: Traceroute Facility for IP Multicast |
| |
|
This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. |
| | Requirements for IP Multicast Session Announcement |
| |
|
The Session Announcement Protocol (SAP) [2] was used to announce information for all available IP multicast sessions to the prospective receiver in an experimental network. It is easy to use, but not scalable and difficult to control the SAP message transmission in a wide area network. This document describes the issues and the requirements for multicast session announcement in the global Internet. |
| | Media Control Channel Framework (CFW) Call Flow Examples |
| |
|
This document provides a list of typical Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. |
| | DHCPv6 Prefix Delegation for NEMO |
| |
| | draft-ietf-mext-nemo-pd-03.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad |
| | Working Group: |
Mobility EXTensions for IPv6 (mext) |
| | Formats: |
txt |
|
One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. |
| | Binding Revocation for IPv6 Mobility |
| |
|
This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified binding(s). |
| | Guidelines for firewall administrators regarding MIPv6 traffic |
| |
|
This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. |
| | Guidelines for firewall vendors regarding MIPv6 traffic |
| |
|
This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6. |
| | Multiple Interfaces Problem Statement |
| |
|
A multihomed host receives node configuration information from each of its provisioning domain. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. |
| | Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| | draft-ietf-mpls-ldp-p2mp-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ina Minei, Kireeti Kompella, IJsbrand Wijnands, Bob Thomas |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
txt |
|
This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/ MP2MP LSP is outside the scope of this document. |
| | Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs |
| |
|
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. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | MPLS-TP OAM Framework |
| |
|
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is based on a profile of the MPLS and pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document describes a framework to support a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [12]. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. |
| | A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations |
| |
|
MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. |
| | Use of TESLA in the ALC and NORM Protocols |
| |
|
This document details the TESLA packet source authentication and packet integrity verification protocol and its integration within the ALC and NORM content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. |
| | PMIPv6 Localized Routing Problem Statement |
| |
|
Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. |
| | Guidelines for Authors and Reviewers of YANG Data Model Documents |
| |
|
This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. |
| | Administration Protocol for Federated Filesystems |
| |
|
This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. |
| | Using DNS SRV to Specify a Global File Name Space with NFS version 4 |
| |
|
The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization- wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. |
| | NSDB Protocol for Federated Filesystems |
| |
|
This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. |
| | HIP Experiment Report |
| |
|
This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. |
| | The 'mailto' URI Scheme |
| |
|
This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). |
| | Simple Service Location Protocol (SSLP) for 6LoWPAN |
| |
| | draft-daniel-6lowpan-sslp-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ki-Hyung Kim, Waleed Baig, Seung Yoo, Soohong Daniel Park, Hamid Mukhtar |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. |
| | Operational Reliability for EDIINT AS2 |
| |
|
The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. |
| | Encrypted Key Transport for Secure RTP |
| |
| | draft-mcgrew-srtp-ekt-06.txt |
| | Date: |
26/10/2009 |
| | Authors: |
David McGrew, Flemming Andreasen, Dan Wing, Lakshminath Dondeti |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTP or SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by early media. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP Key Transport (KTR), and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. |
| | DAI Parameter for the "tel" URI |
| |
| | draft-yu-tel-dai-08.txt |
| | Date: |
26/10/2009 |
| | Authors: |
James Yu, David Hancock, Flemming Andreasen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements. |
| | Internationalized Resource Identifiers (IRIs) |
| |
| | draft-duerst-iri-bis-07.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Martin Duerst, Michel Suignard, Larry Masinter |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. In addition, this document provides named additional rule sets for processing otherwise invalid IRIs, in a way that supports other specifications that wish to mandate common behavior for 'error' handling. In particular, rules used in some XML languages (LEIRI) and web applications are given. Defining IRI as new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: other protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. [RFC Editor: Please remove this paragraph before publication.] This document is intended to update RFC 3987 and move towards IETF Draft Standard. This is an interim version in preparation for the IRI BOF at IETF 76 in Hiroshima. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. |
| | Emulating Border Flow Policing using Re-PCN on Bulk Data |
| |
|
Scaling per flow admission control to the Internet is a hard problem. The approach of combining Diffserv and pre-congestion notification (PCN) provides a service slightly better than Intserv controlled load that scales to networks of any size without needing Diffserv's usual overprovisioning, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It provides a sufficient emulation of per-flow policing at borders but with only passive bulk metering rather than per-flow processing. Measurements are sufficient to apply penalties against cheating neighbour networks. |
| | Six/One: A Solution for Routing and Addressing in IPv6 |
| |
|
There is heightened concern about the growth of the global routing table and the increased frequency of routing table updates. Both is due to the use of provider-independent addressing space in edge networks, which accommodates operators' desire to move traffic quickly and easily from one provider to another. The main recent proposals attempt to solve this problem by hiding provider- independent addressing space through a level of indirection. Unfortunately, indirection requires a non-trivial distribution of address translation information across the Internet. This is either slow, or costly in terms of signaling overhead, or both. Security and transitionability are further issues. This document proposes an alternative solution, which is based on a single, provider-dependent addressing space and hence avoids the problems of indirection. The solution meets the objectives of edge network operators while limiting the size of the routing table and its update frequency. |
| | Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices |
| |
|
The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, the device does not have credentials for network access, does not have a VoIP provider or application service provider (ASP), or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. |
| | A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization |
| |
|
This document describes a framework of Media-independent Pre- Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol and is best applicable to support optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff related operations to take place before the mobile has moved to the new network. We describe the details of all the associated techniques and present the experimental results from the scenarios involving both inter- technology and intra-technology handoff. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. |
| | An IPv6 Geographic |
| |
|
This document defines an IPv6 Geographic global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. |
| | Hierarchical Host Identity Tag Architecture |
| |
|
The current flat-structured Host Identity Tag architecture has various problems and limitation. Hence, a hierarchical HIT architecture that is compatible with the flat-structured HIT architecture is introduced in the document. This architecture and the process of HIT generation ensure the global uniqueness of HITs. This architecture also enables the multiple Host Identity Protocol administrative domains, solves the deployment problem of current flat-structured HIT architecture. It also enhances the scalability and resolution efficiency of the mapping system from HIT to IP or FQDN. |
| | Kerberos Option for DHCPv6 |
| |
|
This document defines a new DHCPv6 option to carry a set of configuration information related to the Kerberos protocol [RFC4120]. This document also defines three sub-options to be used within this new option, which specify a realm name of the Kerberos, a list of IP addresses of the Key Distribution Center of that realm, and a client principal name to distinguish a Kerberos client by the DHCPv6 server. |
| | GMPLS RSVP-TE Recovery Extension for data plane initiated reversion and protection timer signalling |
| |
|
GMPLS RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently recovery signalling does not support the request for revertive protection, neither the configuration of recovery timers. This document extends the PROTECTION Object format allowing sub-TLVs, and defines two sub-TLVs to carry wait-to-restore and hold-off intervals. |
| | A Uniform Resource Name (URN) Namespace for CableLabs |
| |
|
This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. |
| | Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6 |
| |
|
Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. |
| | SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services |
| |
|
This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The URI parameter is extensible to allow future values to be defined if required by other use cases that require specific SIP registrations to be distinctly identified. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. |
| | Routing and Addressing in Next-Generation EnteRprises (RANGER) |
| |
|
RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence. |
| | Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator |
| |
|
Some IPv6 applications obtain IPv4 address literals and want to communicate with those IPv4 hosts through an IPv6/IPv4 translator. The IPv6 application can send an IPv6 packet through the translator if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed; rather, the prefix is chosen by the network operator. This specification provides three methods for a host to learn the IPv6 prefix of its IPv6/IPv4 translator. Unicast, any-source multicast (ASM), and source-specific multicast (SSM) are supported. |
| | Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks |
| |
|
TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques -- such as initial sequence number randomization and source port randomization -- increase the effort required of an attacker to successfully guess the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697. |
| | Creation of a Registry for DNS SRV Record Service Prefixes |
| |
|
The DNS SRV record has been specified in RFC 2052 and RFC 2782. These two RFCs did not specify an IANA registry for names of the services using SRV records as defined by various protocols. This document creates such a registry and populates it. |
| | Real-time Transport Control Protocol (RTCP) in Overlay Multicast |
| |
|
The Real-time Transport Control Protocol (RTCP) is designed to operate along with Real-time Transport Protocol (RTP) in unicast, single-source multicast and any-source multicast environments. With the availability of overlay multicast and Application Layer Multicast (ALM), the suitability of RTCP in such environments needs to be analyzed. The applicability of the existing RTCP reporting architectures in overlay multicast and ALM environments are investigated and the new features that may be required are discussed in this document. |
| | Problems with the use of IPsec as the security protocol for Mobile IPv6 |
| |
|
Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the signaling messages and user plane traffic between the mobile node and home agent. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies. |
| | BGP Prefix Origin Validation |
| |
|
A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. |
| | Virtual IPv6 Connectivity for IPv4-Only Networks |
| |
|
Although the impetus to invest in interworking between IP versions 4 and 6 is initially on the side of early IPv6 adopters, more substantial IPv6 deployment in the future will shift this impetus towards the side of the legacy IPv4 Internet. However, interworking techniques for IPv4-only networks are as yet largely unexplored. This document proposes Virtual IPv6 Connectivity, a technique for IPv4-only networks to communicate with the IPv6 Internet. |
| | The A+P Approach to the IPv4 Address Shortage |
| |
|
We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before we run out of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft discusses the possibility of address sharing by treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a customer device, we propose to extended the address by "stealing" bits from the port number in the TCP/UDP header, leaving the applications a reduced range of ports. This means assigning the same IPv4 address to multiple clients (e.g., CPE, mobile phones), each with its assigned port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core. |
| | Multicast VPN fast upstream failover |
| |
|
This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a standby upstream PE. |
| | IP Router Alert Considerations and Usage |
| |
|
The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use of the IP Router Alert option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendation about protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers. |
| | Port Restricted IP Address Assignment |
| |
| | draft-bajko-pripaddrassign-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Gabor Bajko, Teemu Savolainen, Mohammed Boucadair, Pierre Levis |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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. |
| | A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) |
| |
|
REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. |
| | IPTV Usage for RELOAD |
| |
| | draft-softgear-p2psip-iptv-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Seok-Kap Ko, Young-Han Kim, Seung-Hun Oh, Byoung-Tak Lee, Victor Pascual |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines a P2P IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides the functionality of IPTV servers in a fully-distributed system using P2PSIP RELOAD. The IPTV Usage provides the metadata storage, channel peer list storage, and channel peer group storage using the P2PSIP overlay. This documents defines three kinds about these usages. |
| | MPLS-TP Linear Protection |
| |
|
The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF and ITU-T includes requirements documents and framework documents. The framework documents define the basic architecture that is needed in order to support various aspects of the required behavior. This document addresses the functionality described in the Survivability Framework document [11] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. |
| | Recommendations for Checksum Error LSP Processing in IS-IS |
| |
|
RFC3719 discusses a number of differences between the IS-IS protocol as described in ISO 10589 and the protocol as it is deployed today. This document discusses some other differences found in the China Mobile's backbone network which is constructed with routers from several manufacturers. The differences include LSP checksum calculation, zero checksum LSP processing, zero remaining lifetime LSP processing, and corrupt LSP processing. |
| | Issues with IP Address Sharing |
| |
|
The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues and this memo attempts to identify those common to all such address sharing approaches. Solution specific discussions are out of scope. |
| | Top Level Domain Name Specification |
| |
|
The precise syntax allowed in top-level domain name labels has been the subject to some debate. RFC 1123, for example, makes the statement that top-level domain names are "alphabetic". This document updates the definition of allowable top-level domain names in order to support internationalized domain names (IDNs), as encoded by the IDNA protocols. This document focuses narrowly on the issue of IDNs and does not make any other changes or clarifications to existing domain name syntax rules. |
| | Public Safety Answering Point (PSAP) Callbacks |
| |
|
After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication or for a clarification. For example, the call may have been dropped by accident without the call-taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, then be treated like any other call and as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture addresses callbacks in a limited fashion and thereby covers a couple of scenarios. This document discusses some shortcomings and raises the question whether additional solution techniques are needed. |
| | A Pragmatic Approach for Reducing Delays in Publishing Documents within the Real-time Applications and Infrastructure (RAI) Area |
| |
|
During the last year, participants in the Real-time Applications and Infrastructure (RAI) area have been quite active in discussing proposals that could improve their way of working. This document is a contribution to that discussion and focuses on the reduction of delays experienced in producing specifications. We believe that this is one of the main problems in the RAI area (and quite likely in other areas of the IETF as well) and it requires attention. A number of side effects, caused by the long specification work, are illustrated in this document. |
| | Benchmarking Methodology for Content-Aware Network Devices |
| |
|
The purpose of this document is to define a series of test scenarios which may be used to generate statistics that should help to better understand the performance of network devices under realistic loading conditions. Additionally, this document provides suggestions on which statistics may be the most useful for determining network device performance under realistic deployment scenarios. |
| | draft-hancock-sip-interconnect-guidelines-02 |
| |
|
As Session Initiation Protocol (SIP) peering becomes more widely accepted by service providers the need to define an interconnect guideline becomes of greater value. This document takes into consideration the SIP and commonly used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers (SSPs) to implement within their signaling functions (SFs) or Signaling Path Border Elements (SBEs) for peering. |
| | IAB Thoughts on IPv6 Network Address Translation |
| |
| | draft-iab-ipv6-nat-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Dave Thaler, Lixia Zhang, Gregory Lebovitz |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. |
| | Local Mobility Anchor Resolution for PMIPv6 |
| |
|
The IETF is specifying Diameter extensions to support mobility service authorization and home network prefix allocation for Proxy Mobile IPv6. The protocol operates between a Local Mobility Anchor and a AAA server. Furthermore, the associated specification extends the existing protocol for network access service to support dynamic assignment and discovery of a Local Mobility Anchor during the authentication procedure. The AAA server maintains mobile nodes' profile in a policy store, which includes information about the assigned Local Mobility Anchor as well as the home network prefix. This document proposes a further extension to allow Local Mobility Anchors benefit from the AAA server's policy store and resolve an unknown mobile node's IP address into a routable address of its assigned Local Mobility Anchor. |
| | Trunk Group Use in ENUM |
| |
|
This document describes a method for incorporating trunk group parameters into an E.164 Number Mapping (ENUM) response for the Session Initiation Protocol (SIP) [RFC3261] service URI. It defines the use of trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. |
| | The Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications |
| |
| | draft-naslund-srtp-saf-03.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This memo describes the use of so called store-and-forward cryptographic transforms within the Secure Real-time Transport Protocol (SRTP). The motivation is to support use cases when two end-points communicate via one (or more) store-and-forward middleboxes that are not fully trusted to access the media content. One of the main aspects of the transform is to make the confidentiality and message authentication independent of the RTP header. Another central aspect is to enable identification of the cryptographic context (keys etc.). Besides the security of the end- points, also trust assumptions regarding the store-and-forward middleboxes are addressed. |
| | Optimized Local Routing for PMIPv6 |
| |
|
Base Proxy Mobile IPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, local routing has been defined to allow mobile nodes attached to the same or different mobile access gateways to exchange traffic by using local forwarding or a direct tunnel between the gateways. This document proposes an initiation method and fast handover mechanisms for local routing. The solutions aim at reducing handover delay and packet loss. |
| | ALTO Protocol |
| |
|
Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what an Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. |
| | Guidelines for the use of Variable Bit Rate Audio with Secure RTP |
| |
|
This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. |
| | Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1 |
| |
|
This document defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. |
| | DHCPv6 Extension for Configuring Hosts with Multiple Interfaces |
| |
|
This document defines DHCPv6 Options to configure a multi-homed host's routing table with new entries when the host attaches to a new network on a new interface. |
| | Proxy MIP extension for local routing optimization |
| |
|
This document extends local routing in proxy Mobile IPv6 and defines a localized routing optimization protocol within one PMIPv6 domain. The protocol supports IPv4 transport network operation, IPv4 home address mobility and handover. The Local mobility anchor/mobile access gateway initiates local routing for the mobile and correspondent node by sending messages to each mobile access gateway/local mobility anchor. In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways attached by the correspondent node to the mobile access gateway attached by the mobile node afterwards. Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages. |
| | Evolution Towards Global Routing Scalability |
| |
|
Internet routing scalability has long been considered a serious problem. Although many efforts have been devoted to address this problem over the years, the IETF community as a whole is yet to achieve a shared understanding on what is the best way forward. In this draft, we step up a level to re-examine the problem and the ongoing efforts. we conclude that, to effectively solve the routing scalability problem, we first need a clear understanding on how to introduce solutions to the Internet which is a global scale deployed system. In this draft we sketch out our reasoning on the need for an evolutionary path towards scaling the global routing system, instead of attempting to introduce a brand new design. |
| | PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths |
| |
|
The ability to compute constrained Point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2009.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. |
| | 6LoWPAN Management Information Base |
| |
| | draft-daniel-6lowpan-mib-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ki-Hyung Kim, Hamid Mukhtar, Seong-Soon Joo, Seung Yoo, Soohong Daniel Park |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
This draft defines a portion of the Management Information Base (MIB), the lowpan MIB for use with network management protocols. In particular it defines objects for managing functions related to a 6LoWPAN entity. |
| | SAVI Solution for DHCPv4/v6 |
| |
| | draft-bi-savi-cps-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Jun Bi, Guang Yao, Jianping Wu, Fred Baker |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies the procedure of setting up bindings between DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses. |
| | Source FEC Payload Mapping Information for Sequence Flow |
| |
|
Per FEC Framework, FEC source packet carries source FEC payload ID for FEC protection of arbitrary packet flow. Source FEC payload ID will contain information identifying the source block and the position within the source block. However, in order to maintain backwards compatibility, this document enables the receiver to get this information without appending source FEC payload ID. This information is obtained using the combination of information provided in the FEC payload header and source FEC payload mapping information unit (MIU). Therefore, both non-FEC- capable and FEC-capable receivers can work together in a multicast session. Two ways to signal the source block structure are defined, one for general procedure and anther for systematic procedure that the order of the packets in the source block is deterministic. |
| | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP - reliable bytestream - and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. |
| | The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS |
| |
|
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known, a priori, various techniques can be employed to derive an optimum path. If the domains are simply- connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document provides mechanisms that allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived. |
| | Host Identifier Revocation in HIP |
| |
|
This document mainly analyzes the key revocation issue with host identities (HIs) in the Host Identity Protocol (HIP), which has not attracted enough attention from the HIP community yet. As a key functionality of key management mechanisms, key revocation is critical for security systems especially which are expected to operate for a long period. Apart from that, this document also discusses the potential challenges that the designers of HI revocation mechanisms have to encounter and propose candidate solutions. |
| | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
|
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. |
| | Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP |
| |
|
There is widespread interest in using the Hypertext Transfer Protocol (HTTP) to enable asynchronous or server-initiated communication from a server to a client as well as from a client to a server. This document describes how to better use HTTP, as it exists today, to enable such "bidirectional HTTP" using "long polling" and "HTTP streaming" mechanisms. |
| | A Real-Time Transport Protocol (RTP) Extension Header for Mixer-to- client Audio Level Indication |
| |
|
This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of the individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. |
| | Softwire Concentrator Discovery Using DHCP |
| |
|
Several types of Carrier Grade NATs have been proposed to simplify IPv4/IPv6 transition of the edge network by integrating tunnels and NAT. A very common scenario is that many users set up softwires to a softwire concentrator for public or private access services. In order to establish softwires successfully, a new mechanism is required to enable users in the edge network to discover the information of the concentrator. This document describes how a host or Customer Premises Equipment discovers the remote softwire concentrator or CGN in a hub and spoke network using DHCP. Based on two new Softwire Concentrator Discovery DHCP Options, proposed in the document, a user can obtain the information of the softwire concentrator or CGN and then set up a tunnel to it. |
| | Return Path Specified LSP Ping |
| |
|
This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. |
| | Framework for IPv4/IPv6 Multicast Translation |
| |
|
This draft describes how IPv4/IPv6 multicast translation may be used in various scenarios and attempts to be a framework for possible solutions. This can be seen as a companion document to the draft "Framework for IPv4/IPv6 translation" by Baker et al. When considering scenarios and solutions for unicast translation, one should also see how they may be extended to provide multicast translation. |
| | Multihoming extensions for Proxy Mobile IPv6 |
| |
| | draft-bernardos-mif-pmip-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Carlos Bernardos, Telemaco Melia, Pierrick Seite, Jouni Korhonen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The IETF standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi- homing support to multi-mode mobile devices. The IETF is working on optimizations for PMIPv6. While multi-homing item has been proposed to be part of the approved work, discussions showed there are still many controversial issues to be addressed (i.e. the no-host modification theorem). This document explores solutions for the multi-homing use case aiming at helping PMIPv6 development where possible. |
| | Multiple Preemption Priority Policy Element for RSVP |
| |
|
RSVP Extensions are being defined allowing an endpoint to signal alternate "bandwidths" of interest in case the preferred bandwidth is not available and allowing the RSVP routers to collectively establish the reservation with the highest currently achievable bandwidth among the signaled set. This can be used to achieve efficient dynamic endpoint codec adjustment. The present document presents a complementary set of extensions, allowing the dynamic bandwidth selection to reflect a different reservation priority for each of the multiple "bandwidth" associated with a reservation. |
| | Mobile Multicasting Support in Proxy Mobile IPv6 |
| |
|
To support IP-based group communication such as mobile IPTV in mobile environment, IP multicasting is required. For minimized burden and modification on PMIPv6 components, multicasting architecture is required to determine where to locate the multicast router (MR) and how to operate IGMP/MLD action in PMIPv6 network. To deploy PMIPv6 multicasting, there are two possible approaches: tunnel forwarding and direct routing scenario. But, this draft focuses direct routing scenario based PMIPv6 multicasting architecture that do not require MR function within the LMA and handover mechanism and describes IGMP/MLD operation. Our solution is easy to deploy and save bandwidth usage. And it solves the tunnel convergence problem without PMIPv6 modification. |
| | NFSv4 Multi-Domain Access |
| |
|
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. |
| | Traffic safety applications requirements |
| |
|
This document describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer. These traffic safety applications and requirements have been derived by the USA VSC (Vehicular Safety Communications)and VSC-A (VSC-Applications) projects and by the European Car to Car Communication Consortium (C2C-CC) and the ETSI TC ITS standardization body. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions. |
| | Synchronized Playback in Rapid Acquisition of Multicast Sessions |
| |
|
When watching the same IPTV channel, different TV sets may not render the same picture and the associated audio at the same moment. The variation in end-to-end delay that resulted in such asynchronous playback between users is referred to as inter-user playback delay. Unicast based rapid acquisition of multicast RTP sessions (RAMS) as specified in [I-D.ietf-avt-rapid-acquisition- for-rtp] is an important technique in achieving fast channel switching in IPTV as well as other multicast applications. In addition, RAMS also significantly relaxes the requirement of relatively short random access point period in encoding of video streams in multicast applications, thus allowing significantly improved compression efficiency. However, on the other hand, the use of RAMS increases inter-user playback delay, which makes users receiving the same multicast session playback the same content asynchronously. This document specifies a mechanism to help reduce inter-user playback delay caused by the use of RAMS. |
| | IGMP and MLD Optimization for Mobile Hosts and Routers |
| |
|
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. |
| | LDP Multipoint Opaque Value Element Types |
| |
|
[MLDP] describes extensions to the Label Distribution Protocol (LDP) for setup of point to multi-point (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class (FEC) elements used to establish P2MP and MP2MP LSPs include type- length-value (TLV) fields that carry information meaningful to Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in [MLDP]. This document defines Opaque Value Element structure to be used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for Multicast Virtual Private Network (MVPN). It is envisioned that this would be useful for security and manageability of P-Tunnels used for MVPN from the ones provisioned for other applications and vice-versa. |
| | Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) |
| |
|
In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. |
| | Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/IPv6 Transition |
| |
| | draft-chen-behave-rsnat-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Linjian Song, Yong Cui |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/IPv6 co-existence/transition would be a long period. In the IPv4/IPv6 transition process, there are many NAT- like technologies active in the internet. However, the NAT boxes such as IPv4 NAT, IPv4/IPv6 NAT are so poor in their reliability and scalability, which put a severe threat on the development of IPv4/IPv6 transition. This document defines a reliable and scalable NAT (RS- NAT) mechanism to solve the problem. |
| | Threat to BGP Policies : limited-scope more specific prefix injection |
| |
|
This draft describes potential threats to the respect of Internet routing policies by the routers of one ISP, that are due to a restricted propagation of more specific BGP prefixes by its neighboring domains. |
| | IPPM standard compliance testing |
| |
|
This document specifies tests to determine if multiple, independent, and interoperable implementations of a metrics specification document are at hand so that the metrics specification can be advanced to an Internet standard. Results of different IPPM implementations can be compared if they measure under the same underlying network conditions. Results are compared using state of the art statistical methods. |
| | Indication of Client Failure in MPLS-TP |
| |
|
This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) tool to propagate a client failure indication across an MPLS-TP network in case the propagation of failure status in the client layer is not supported. |
| | The Diameter Precongestion Notification (PCN) Data Collection Application |
| |
|
Pre-Congestion notification (PCN) is a technique for maintaining QoS for inelastic flows in a DIFFServ domain. The PCN architecture requires that egress nodes send reports of congestion-related events reliably to a policy decision point. The policy decision point might be located in different places of the network. In one architectural variant the policy decision point is a central node rather than co- located with the ingress or the egress nodes of the network. In this case it needs to have access to certain information from the edge nodes. This memo defines a Diameter application to support the ingress and the egress node to interact with the Diameter server acting as a policy decision point. |
| | GMPLS RSVP-TE Extensions for OTN and SONET/SDH OAM Configuration |
| |
|
GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK]. |
| | Mechanisms for Media Source Selection in the Session Description Protocol (SDP) |
| |
|
Source-specific media attributes in the Session Description Protocol (SDP) allow endpoints to describe Real-Time Transport Protocol (RTP) sources within a media stream. This document extends that mechanism by defining how participants in a multimedia session can request specific sources from a remote party. |
| | DNS Extensions to Support IPv4 and IPv6 |
| |
|
In the DNS architecture, two kinds of record types for maintaining host's IP addresses are supported: one is A type which records IPv4 and AAAA for IPv6 addresses. This document defines a new TYPE, which is mainly used in queries in order to get both IPv4 and IPv6 addresses. The main advantage is to avoid sending several requests in order to resolve the location of a given resource. A single request may be sufficient. The proposed solution does not require the definition of any new record type. |
| | LMA Handovers for Proxy Mobile IPv6 |
| |
|
This document describes a mechanism for context transfer between Local Mobility Anchors (LMAs) in a large Proxy MIPv6 domain to provide the IP ongoing session continuity of mobile nodes. In order to enhance the performance of the LMA handover, a bi-directional tunnel between a previous LMA and a new target LMA is established. |
| | Extending YANG with Language Abstractions |
| |
|
YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests to enhance YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. |
| | Fundamental Elliptic Curve Cryptography Algorithms |
| |
|
This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they are defined in some early references. These descriptions may be useful to those who want to implement the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. |
| | LSP-Ping and BFD encapsulation over ACH |
| |
|
LSP-Ping and BFD for MPLS are existing and widely deployment OAM mechanisms for MPLS LSPs. This document describes ACH encapsulation for LSP-Ping, to enable use of LSP-Ping when IP addressing is not in use. This document also clarifies the use of BFD for MPLS LSPs using ACH encapsulation, when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP. |
| | Dynamic Port Range Re-Assignments for Address Sharing |
| |
|
This document proposes an extension regarding dynamic port range re- assignment to an IPv4 address sharing framework (SHARA), to overcome IPv4 address shortage. It allows an entity which is responsible for IPv4 address and port distribution to apply dynamic handling of already assigned port ranges. An adjustment of number of ports per customer according to the current consumption pattern is possible with this enhancement. |
| | MPLS-TP Identifiers |
| |
|
This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. |
| | Improved Rapid Acquisition of Multicast Sessions |
| |
|
This document describes two improvements to unicast based rapid acquisition of multicast RTP sessions (RAMS) described in [I- D.ietf-avt-rapid-acquisition-for-rtp]. One improved method allows a receiver to simultaneously request a unicast burst stream and join the multicast group, and then select one of the two streams to be first processed. Another method proposes to optionally convey a parameter called unicast backspace in the RAMS-I message. This parameter can be used by RR to determine when to join the primary multicast session. |
| | MPLS-TP Ring Protection |
| |
|
This document describes mechanisms to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Ring topologies offer the possibility of reducing the OAM overhead while providing a simplified protection mechanism. The document analyzes two basic ring protection schemes and explains how ring protection can be viewed as an application of linear protection. |
| | Explicit Congestion Notification (ECN) for RTP over UDP |
| |
|
This document specifies how explicit congestion notification (ECN) can be used with RTP/UDP flows that use RTCP as feedback mechanism. |
| | IPv4/IPv6 Coexistence Framework (PET) |
| |
| | draft-cui-softwire-pet-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Yong Cui, Mingwei Xu, Shengling Wang, Jianping Wu, Xing Li, Chris Metz |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence technologies, which can be generally divided into two categories: translation and tunneling. Both translation and tunneling have limitations and application scopes. In some typical transition scenarios, tunneling and translation are needed at the same time. In addition, there may be multiple network devices capable of doing translation or tunneling along the end-to-end path. It's important to choose particular device(devices) for doing translation or tunneling. This draft presents an IPv4-IPv6 transition/coexistence framework named PET (short for Prefixing, Encapsulation and Translation). PET is a network side solution which includes fundamental elements needed in various transition scenarios. In PET framework, signaling is required for transition devices to exchange necessary information and negotiate how to do combine transition and tunneling cooperatively. This draft also addresses how to deploy PETs and analyze the advantages and disadvantages of typical transition technologies that PET may adopt. |
| | Naming Architecture for Object to Object Communications |
| |
| | draft-lee-object-naming-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Noel Crespi, Gyu Myoung Lee, Jun Kyun Choi, Seng Kyoun Jo, Jeong Yun Kim |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document explains the concept of object to object communications and describes naming issues for object identification. In order to develop protocols for object to object communications, this document provides the naming architecture according to mapping relationships between host and object(s). In addition, considerations of protocols for naming object are specified. |
| | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for evolutive OTNs control |
| |
|
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN) based on ITU-T G.709 Amendment 3 reccomandation. References also to G.sup43 are provided. |
| | IPv6 Customer Edge Router Recommendations(bis) |
| |
|
This document continues the work undertaken by a earlier version of this document that has been a IETF v6ops working Group document. The Working Group preferred to expedite the IPv6 CE Router document with basic technology requirements. Any leftover work is continued in this document and considered as Phase two effort. |
| | IPv6 IPv4 translation FTP considerations |
| |
|
The File transfer protocol, which is defined by the RFC 959, has a long history, but still widely used today. The original version of FTP specification defines IPv4 FTP which means it assumes the IP version is IPv4. RFC 2428 defines IPv6 extensions of FTP, introducing EPRT and EPSV command. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document gives guidelines for the FTP client, server and the translation box to ensue FTP working properly in the IPv4-IPv6 transition scenario. |
| | Third-party ALTO server discovery |
| |
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This document describes why a third-party ALTO server discovery mechanism is required for an important class of applications, namely tracker-based P2P applications. Several solution approaches are classified and evaluated. The conclusion is that further work is required to standardize a protocol and procedures that follow one specific approach. |
| | Guidelines for Proposed CODEC Working Group |
| |
| | draft-valin-codec-guidelines-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Jean-Marc Valin, Peter Saint-Andre, Slava Borilin, Koen Vos, Christopher Montgomery, Juin-Hwey Chen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document provides general guidelines for work on specifying audio codecs within the IETF. These guidelines cover the development process, evaluation and requirements conformance, and intellectual property issues. |
| | Codec Requirements |
| |
| | draft-valin-codec-requirements-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Jean-Marc Valin, Slava Borilin, Koen Vos, Christopher Montgomery, Juin-Hwey Chen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document provides specific requirements for Internet audio codecs. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. |
| | The Need for Congestion Exposure in the Internet |
| |
|
Today's Internet is a product of its history. TCP is the main transport protocol responsible for sharing out bandwidth and preventing a recurrence of congestion collapse while packet drop is the primary signal of congestion at bottlenecks. Since packet drop (and increased delay) impacts all their customers negatively, network operators would like to be able to distinguish between overly aggressive congestion control and a confluence of many low-bandwidth, low-impact flows. But they are unable to see the actual congestion signal and thus, they have to implement bandwidth and/or usage limits based on the only information they can see or measure (the contents of the packet headers and the rate of the traffic). Such measures don't solve the packet-drop problems effectively and are leading to calls for government regulation (which also won't solve the problem). We propose congestion exposure as a possible solution. This allows packets to carry an accurate prediction of the congestion they expect to cause downstream thus allowing it to be visible to ISPs and network operators. This memo sets out the motivations for congestion exposure and introduces a strawman protocol designed to achieve congestion exposure. |
| | Uniform Resource Identifier (URI) Parameters for indicating the Calling Party's Catagory and Originating Line Identity |
| |
|
This document defines two new URI parameters to describe the calling party's category and toll class of service originating line information which are parameters also used in SS7 ISUP and other telephony signalling protocols. The intended use of these URI parameters is for the tel URI and SIP URI address schemes. |
| | Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators |
| |
|
A small percentage of HTTP URIs contain an IPv4 address literal as the hostname which is not accessible to IPv6-only HTTP clients using an IPv6/IPv4 translator and DNS64. This document proposes a workaround for this problem using an HTTP proxy to handle that traffic. |
| | Adding the "find" Operation to the dtn: URI Scheme |
| |
|
This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new "find" operation would provide support for DTN (Delay- and Disruption-Tolerant Network) anycast services. |
| | Gateway Initiated Dual-Stack Lite Deployment |
| |
|
Dual-Stack lite (DS-lite) has been proposed as an IPv4 to IPv6 transition technique. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the customer. The dual-stack lite solution uses an IPv4-over-IPv6 tunnel between a host (or access device) and a dual-stack lite Carrier Grade NAT (CGN). Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling schemes between the access device and an access gateway in the provider network. Applying the dual-stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite CGN using softwires. This evolved approach not only applies to IPv6 networks but also includes support for IPv4 networks. |
| | Session Initiation Protocol (SIP) Domain Registration |
| |
|
This document defines a means of providing reachability information for a domain of SIP AoR's using a SIP REGISTER method transaction. |
| | Subscription/Notification for Lightweight Directory Access Protocol (LDAP) |
| |
|
This document extends Lightweight Directory Access Protocol (LDAP) to support subscription and notification mechanism. An LDAP client can subscribe to data of interest available from an LDAP server and receive notifications from the LDAP server when this data is updated. By this means, an LDAP client can become aware of changes to data of interest in a timely manner. |
| | Proactive Connection Verification,Continuity Check and Remote Defect indication for MPLS Transport Profile |
| |
|
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). |
| | Requirements for NFSv4.2 |
| |
|
This document proposes requirements for NFSv4.2. |
| | Addressing Model for Router Interfaces in Ad Hoc Networks |
| |
|
This document describes a practical IP addressing model for interfaces that take part in router-to-router communications in ad hoc networks. |
| | PMIPv6 operation with IEEE 802.21 |
| |
|
The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi-homing support to multi-mode mobile devices. While the basic scenario addressed by PMIPv6 considers MNs with just one interface, PMIPv6 also allows an MN to connect to the same PMIPv6 domain through different interfaces. This limited support of multi- interfaced MNs is not fully specified, since the MAG needs to obtain/ guess additional information from the MN, in order to decide whether to treat an MN's interface attachment as a handover or as new interface attachment (i.e. meaning the creation of a new mobility session and, therefore, the allocation of new home network prefixes to the MN). The use of the Media Independent Handover (MIH) Services as defined in the IEEE 802.21-2008 specification [IEEE80221] may help in obtaining this additional information. This I-D describes how PMIPv6 would work in an 802.21-enabled scenario, and in particular, analyzes how MIH primitives can be used to help the MAG deal with multi-technology scenarios. The main objective of the IEEE 802.21- 2008 standard is to provide link layer intelligence to upper layers. Hence, a more intelligent decision making capability leading to more reliable and efficient handovers between heterogeneous networks can be enabled. |
| | Requirements for Referral in Mobile Network,input to GROBJ BoF |
| |
|
This document lays out the requirements that need to be met by the potential referral modifications for the mobile network. |
| | A Optimal Load-balance mechanism for NAT64 (OL-NAT) |
| |
|
In NAT64 scenaires,sigle-point failure is a critical issue to restrict large-scale deployment. In order to overcome this hurdle, this memo proposed a optimal load-balance mechanism for NAT64. Through the new-defined evaluation metrics, several extended ICMP messages combining with anycast are performed to achieve optimal NAT64 selection. Meanwihle, the synchroniztion process of IP address mapping information is also designed to guarantee the service continuity. |
| | Stateless Address Mapping (SAM) - Mesh Softwires without e-BGP |
| |
|
SAM is a generic and simple mechanism for packets having addresses in a family IPvX to traverse routing domains where this address family is not directly routed. SAM topological scenarios are those of Mesh Softwire, i.e. with point to multipoint tunnels between border nodes of interior routing domains. In the mesh-softwire context, SAM differs from RFC 5565 in that SAM uses no protocol between border nodes of the domain, and in that customer border nodes don't need to maintain states for all other border nodes. (RFC 5565 is based on an Exterior Border-Gateway Protocol e-BGP between border nodes, with dynamic routing tables to be maintained in all of them). SAM's address mappings are stateless, based on only a few domain parameters. SAM is thus suitable to small to medium enterprises, and small to medium ISPs, that cannot afford e-BGP in all their border nodes. All combinations of IPv4 and IPv6, global or private, are supported. Also, to mitigate consequences of the IPv4 address shortage, SAM supports port-extended IPv4 addresses (A+P). |
| | ALTO Information Redistribution |
| |
|
The ALTO protocol proposes several mechanisms to increase scalability. One of the proposed mechanisms is ALTO information redistribution. This document concretely defines ALTO Information Redistribution, indicates suggested extensions to the ALTO Protocol to support redistribution, and shows how redistribution could be used in practice. |
| | HOKEY Architecture Design |
| |
|
This document describes deployment scenarios of HOKEY architectures in the wireless environment. The design objectives and main components of HOKEY architecture are identified, and examples of how the EAP Re-authentication Protocol (ERP) can be integrated into a HOKEY architecture are discussed. |
| | A Survey of In-network Storage Systems |
| |
|
This document describes existing in-network storage systems and their applicability for DECADE. |
| | Additional functions for OSPFv2 extensions for ASON routing |
| |
|
[OSPF-ASON] defines OSPFv2 extensions to fulfill the requirements defined in [RFC4258]. In OIF discussion of ASON routing, OIF members have noted that some additional functionality beyond that defined in [OSPF-ASON] would be useful for deployment of ASON routing by OIF carriers. The purpose of this document is to list such additional functionalities, so that CCAMP experts study whether such functionalities can be fulfilled by existing GMPLS mechanisms, or whether extensions to [OSPF-ASON] are required. Some proposals for potential extensions are provided for review by IETF CCAMP. |
| | Performance Evaluation of Routing Protocol for Low Power and Lossy Networks (RPL) |
| |
|
This document presents a performance evaluation of RPL in a single DAG scenario, and comparison of the same with shortest path routing in a LLN. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on a set of real- life scenarios. |
| | Virtual interface for supporting multihoming and inter technology handover |
| |
|
The Proxy Mobile IPv6 supports a mobile node to perform inter- technology handover as well as multihoming. However the inter- technology handover requires the new interface to use the same network prefix with the old one and all the IP address/prefix at the old interface are removed. These requirements disable multihoming function which requires different network prefixes for different interfaces. In this Internet draft we address this problem and suggest the necessary changes in PMIPv6 operations to support a mobile node to perform multihoming as well as seamless inter technology handover with virtual interface. |
| | Congestion Exposure Problem Statement |
| |
|
The increasingly ubiquitous availability of broadband, together with flat-rate pricing, have made the use of new kinds of peer-to-peer applications increasingly common. From the perspective of the Internet's evolution and its contributions to end user value, this is very exciting. However, the uptick in peer-to-peer application usage has also contributed to the rise of "high-consuming users" who take their flat-rate contracts to the limit by continuously file-sharing to the maximum extent possible. Network operators have responded to this phenomenon in a number of different fashions. This document discusses the problems created for operators by high- consuming users and illustrates a number of techniques operators are currently using to cope with high bandwidth usage. |
| | A Common API for Transparent Hybrid Multicast |
| |
|
Group communication services are most efficiently implemented on the lowest layer available. However, as the deployment status of multicast distribution largely varies throughout the Intenet, globally operational group solutions are frequently restricted to using a stable, upper layer protocol controlled by the application itself. This document describes a common multicast API that serves the requirements of data distribution and maintenance for multicast and broadcast on a middleware abstraction layer, suitable for transparent underlay and overlay communication. It proposes and discusses mapping mechanisms between different namespaces and forwarding technologies. Additionally, it describes the application of this API at gateways operating between current multicast instances throughout the Internet. |
| | Path Computation Element (PCE) Extensions for Inter-Layer Path Computation |
| |
|
This document mainly describes the extensions of multiple PCE inter- layer path computation with inter-PCE communication. |
| | Relaying HTTP from IPv4 to IPv6 |
| |
|
As IPv6-only hosts become commonplace, it is desirable to still have IPv4 clients access those IPv6-only hosts. Due to the size of the IPv4 and IPv6 address spaces, this has proven difficult using pure IP address translation. Rather than trying to support all IP protocols, or even all TCP or UDP applications, this document proposes a mechanism for an IPv4 HTTP client to connect to an IPv6-only HTTP server. |
| | Building IPv6 Applications which Access IPv4 Servers |
| |
|
When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. |
| | Diameter Parameter Query |
| |
|
In an emergency services environment a Location Information Server (LIS) receives requests from end hosts, SIP proxies or Public Safety Answering Points (PSAPs). When receiving these requests a LIS has to perform a location determination procedure that depends on the specific network deployment. In any case, an interation with other network elements is needed, particularly with AAA servers, that store information about the current attachment of the end host. This document descirbes a Diameter application, called Diameter Parameter Query, which allows a Location Information Server to interact with a Diameter server to obtain information needed for the location determination procedure. The style of the described Diameter application offers flexibility for different deployments. |
| | ECRIT Direct Emergency Calling |
| |
|
The specified IETF emergency services architecture puts a strong emphasis on emergency call and emergency messaging via the Voice Service Provider (VSP) / Application Service Provider (ASP). There are two reasons for this design decision: The call routing via the VSP/ASP is more natural as it follows the standard communication pattern and transition deployments assume non-updated end hosts. As the deployment of the Location-to-Service Translation protocol progresses there are possibilities for upgraded end devices to directly communicate with the IP-based emergency services network without the need to interact with a VSP/ASP, which simplifies the task of regulators as the involved parties are within the same jurisdiction. This memo describes the procedures and operations of a generic emergency calling client utilizing the available building blocks. |
| | AAA Support for PMIP6 mobility entities Locating and Discovery during localized routing |
| |
|
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly by the MAG without involving the LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of local routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be discovered This document specifies how to accomplish these tasks using the Diameter protocol |
| | Address-sharing stateless double IVI |
| |
|
This document presents the concepts and the implementations of address-sharing stateless IVI (stateless 1:N IVI) and the address- sharing stateless double IVI (stateless 1:N dIVI). The stateless 1:N IVI keeps the features of stateless, end-to-end address transparency and bidirectional-initiated communications of the original stateless 1:1 IVI, while it can utilize the IPv4 addresses more effectively. The stateless 1:N dIVI has above features and it does not require the DNS64/DNS46 and ALG supports. |
| | FIB Aggregation |
| |
|
The rapid growth of Forwarding Information Base (FIB) has raised concerns among many Internet Service Providers. One potential solution to this problem is FIB aggregation, i.e. letting each router aggregate its FIB entries without affecting the forwarding paths taken by data traffic. It is a simple local software optimization within a router, requiring no changes to routing protocols or router hardware. To understand the effectiveness of using FIB aggregation to extend router lifetime, in this draft we present several FIB aggregation algorithms and evaluate their performance using routing tables and updates collected from tens of networks. Our results show that FIB aggregation can reduce the FIB table size by as much as 70% with small computational overhead. We also show that the computational overhead can be controlled through various mechanisms. |
| | SD-Triggered Protection Switching in MPLS-TP |
| |
|
In MPLS-TP survivability framework, a fault condition includes both Signal Failure (SF) and Signal Degrade (SD) that can be used to trigger protection switching. This document describes Signal Degrade (SD) detection and the consequent protection switching mechanism. |
| | A Survey of Mobility Support In the Internet |
| |
|
Over the last two decades many research efforts have been devoted to developing solutions for mobility support over the global Internet, which resulted in a variety of proposed solutions. In this draft we conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This draft reports our finding and identifies remaining issues in providing ubiquitous and efficient global scale mobility support. |
| | (Dual Stack) Mobile IPv6 Implementation with unmodified IPsec |
| |
|
It's been argued in the past and in some documents, such as RFC 3776, RFC 4877 and RFC 5555, that an IPsec implementation needs to be modified to afford security services to MIPv6 and DSMIPv6. This document shows that it is possible to implement MIPv6 and DSMIPv6 in a way that does not require change to a native or Bump-in-the-stack (BITS) IPsec implementation conformant to RFC 4301. |
| | MPLS-TP OAM maintenance points |
| |
|
MPLS transport profile (MPLS-TP) is expected to be one of the promising future transport technologies which will realize carrier grade packet transport network and complement future development of network. One of the most important features in MPLS-TP is the OAM tool/function which enables operators or service providers to provide various kinds of service characteristics such as prompt fault location, substantial survivability, performance monitoring, preliminary or in-service measurement and so on. Considering those new feature as transport profile, the definition of the maintenance points at which OAM messages are initiated, terminated and reacted are very important. This document describes the guidance and requirements regarding those maintenance points in MPLS-TP network. |
| | Requirements for Session Recording Protocol (SRP) |
| |
|
Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically done by sending a copy of the media to the recording devices. This document specifies requirements for a protocol that will manage delivery of media from an end-point that originates media or that has access to it to a recording device. This protocol is being referred to as Session Recording Protocol and will most likely be based on SIP. |
| | NSLP for Quality-of-Service Signaling |
| |
|
This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. |
| | Recommendations for filtering ICMP messages |
| |
|
This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. |
| | Definitions of Managed Objects for Path Computation Element Discovery |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stephan, et al. Expires April 27, 2009 [page 1] draft-ietf-pce-disc-mib-04 October 2009 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | Definitions of Textual Conventions for Path Computation Element |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stephan, et al. [page 1] draft-ietf-pce-tc-mib-05 October 2009 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| | draft-ietf-pce-pcep-p2mp-extensions-05.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Quintin Zhao, Daniel King, Fabien Verhaeghe, Tomonori Takeda, Zafar Ali, Julien Meuric, Jean-Louis Le Roux, Mohamad Chaitou |
| | Working Group: |
Path Computation Element (pce) |
| | Formats: |
txt |
|
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | Pre-Congestion Notification Encoding Comparison |
| |
| | draft-ietf-pcn-encoding-comparison-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Kwok Chan, Georgios Karagiannis, T Moncaster, Michael Menth, Philip Eardley, Bob Briscoe |
| | Working Group: |
Congestion and Pre-Congestion Notification (pcn) |
| | Formats: |
txt |
|
A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document collects the lessons learned as we explore the different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide information on trade offs with the encoding choices, providing guidance based on different criteria. This document provides a historical trace of the consideration on different encoding alternatives for Pre-Congestion Notification. |
| | Authentication and Confidentiality in PIM-SM Link-local Messages |
| |
|
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional support for automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. |
| | A Reliable Transport Mechanism for PIM |
| |
| | draft-ietf-pim-port-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Dino Farinacci, IJsbrand Wijnands, Stig Venaas, Maria Napierala |
| | Working Group: |
Protocol Independent Multicast (pim) |
| | Formats: |
txt xml |
|
This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. |
| | PIM Multi-Topology ID (MT-ID) Join-Attribute |
| |
|
This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. |
| | Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP |
| |
|
This document describes how to layer Certificate Management Protocols over various transport protocols. |
| | ESSCertIDv2 update for RFC 3161 |
| |
|
This document updates RFC 3161 [RFC3161]. It allows the use of ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a signer certificate when the hash is calculated with a function other than SHA-1 [SHA1]. |
| | Framework for Performance Metric Development |
| |
|
This document describes a framework and a process for developing performance metrics for IP-based applications that operate over reliable or datagram transport protocols, and that can be used to characterize traffic on live networks and services. The framework refers to a Performance Metrics Entity, or PM Entity, which may in future be a working group or directorate or a combination of these two. |
| | Preferential Forwarding Status bit definition |
| |
|
This document describes a mechanism for standby status signaling of redundant PWs between their termination points. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate a preferential forwarding status of active or standby for each PW in the redundancy set. In addition, a second status bit is defined to allow peer PE/T-PE nodes to coordinate a switchover operation of the PW/MS-PW path. |
| | Pseudowire (PW) Redundancy |
| |
|
This document describes a framework comprised of few scenarios and associated requirements where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. |
| | Simple Authentication Schemes for the ALC and NORM Protocols |
| |
|
This document introduces four schemes that provide a per-packet authentication and integrity service in the context of the ALC and NORM protocols. The first scheme is based on digital signatures. Because it relies on asymmetric cryptography, this scheme generates a high processing load at the sender and to a lesser extent at a receiver, as well as a significant transmission overhead. It is therefore well suited to low data rate sessions. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). If this approach also relies an asymmetric cryptography, the processing load and the transmission overhead are significantly reduced compared to traditional digital signature schemes. It is therefore well suited to medium data rate sessions. The third scheme relies on a group Message Authentication Code (MAC). Because this scheme relies on symmetric cryptography, MAC calculation and verification are fast operations, which makes it suited to high data rate sessions. However it only provides a group authentication and integrity service, which means that it only protects against attackers that are not group members. Finally, the fourth scheme merges the digital signature and group group schemes, and is useful to mitigate DoS attacks coming from attackers that are not group members. |
| | Routing Metrics used for Path Calculation in Low Power and Lossy Networks |
| |
|
Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs. |
| | RPL: IPv6 Routing Protocol for Low power and Lossy Networks |
| |
| | draft-ietf-roll-rpl-04.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Tim Winter, Pascal Thubert, ROLL Team |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
| | Formats: |
txt xml |
|
Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of LLN routers, and support point-to- point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint-to- point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. |
| | FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses |
| |
| | draft-ietf-savi-fcfs-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Erik Nordmark, Marcelo Bagnulo, Eric Levy-Abegnoli |
| | Working Group: |
Source Address Validation Improvements (savi) |
| | Formats: |
txt |
|
This memo describes FCFS SAVI a mechanism to provide source address validation for 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. |
| | SEND-based Source-Address Validation Implementation |
| |
| | draft-ietf-savi-send-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Marcelo Bagnulo, Alberto Garcia-Martinez |
| | Working Group: |
Source Address Validation Improvements (savi) |
| | Formats: |
txt |
|
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. |
| | Socket Application Program Interface (API) for Multihoming Shim |
| |
|
This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration. This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. |
| | An Infrastructure to Support Secure Internet Routing |
| |
|
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. |
| | A Profile for Route Origin Authorizations (ROAs) |
| |
|
This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. |
| | Dual-stack lite broadband deployments post IPv4 exhaustion |
| |
|
This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. Dual-stack lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and NAT. |
| | IPv6 via IPv4 Service Provider Networks |
| |
|
This document specifies a protocol mechanism tailored to advance deployment of IPv6 to end users via a Service Provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service which is equivalent to native IPv6 at the sites which are served by the mechanism. |
| | SPEERMINT Requirements for SIP-based Session Peering |
| |
|
This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the SPEERMINT working group. This informational document is intended to link the session peering use cases to protocol solutions. |
| | Transport Layer Security (TLS) Extensions: Extension Definitions |
| |
|
This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. |
| | Rbridges: Base Protocol Specification |
| |
| | draft-ietf-trill-rbridge-protocol-14.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Donald Eastlake 3rd, Dinesh Dutt, Silvano Gai, Anoop Ghanwani, Radia Perlman |
| | Working Group: |
Transparent Interconnection of Lots of Links (trill) |
| | Formats: |
txt |
|
RBridges provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. |
| | RSVP Proxy Approaches |
| |
|
The Resource ReSerVation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP Proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP Proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP Proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP Proxy are described. |
| | RSVP Extensions for Path-Triggered RSVP Receiver Proxy |
| |
|
RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. |
| | Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry |
| |
| | draft-ietf-tsvwg-iana-ports-03.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Michelle Cotton, Lars Eggert, Allison Mankin, Joseph Touch, Magnus Westerlund |
| | Working Group: |
Transport Area Working Group (tsvwg) |
| | Formats: |
txt xml |
|
This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling registration and other requests related to the transport protocol port number and service name registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates RFC2780 by obsoleting Sections 8 and 9.1 of that RFC, it updates the IANA allocation procedures for DCCP as defined in RFC4340, and it updates RFC2782 to clarify what a service name is and how it is registered. |
| | Tunnelling of Explicit Congestion Notification |
| |
|
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP in IP tunnel. On encapsulation it updates RFC3168 to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec ECN processing. On decapsulation it updates both RFC3168 and RFC4301 to add new behaviours for previously unused combinations of inner and outer header. The new rules propagate the ECN field whether it is used to signal one or two severity levels of congestion, whereas before they propagated only one. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field (backward compatible). Nonetheless, operators wanting to support two severity levels (e.g. for pre-congestion notification--PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. |
| | Stream Control Transmission Protocol (SCTP) Stream Reconfiguration |
| |
|
Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". This documents presents also a method for resetting the transport sequence numbers and all stream sequence numbers. |
| | Requirements for IPv6 Customer Edge Routers |
| |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. |
