| draft-abiri-cpfp-00.txt | |||||||||||||||||
| Certified Pan Formation Protocol | |||||||||||||||||
|
This draft introduces the Certified PN Formation Protocol (CPFP) based on the personal public key infrastructure (personal PKI) concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques by using ECDH, ECDSA and STS protocols and provides feasible solutions for key revocation and transitive imprinting. | ||||||||||||||||
| draft-aboba-radext-wlan-09.txt | |||||||||||||||||
| RADIUS Attributes for IEEE 802 Networks | |||||||||||||||||
|
RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter. | ||||||||||||||||
| draft-acee-ospf-multi-instance-02.txt | |||||||||||||||||
| OSPF Multi-Instance Extensions | |||||||||||||||||
|
OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. | ||||||||||||||||
| draft-acee-ospf-transport-instance-01.txt | |||||||||||||||||
| OSPF Transport Instance Extensions | |||||||||||||||||
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. | ||||||||||||||||
| draft-adams-tsvwg-flow-signalling-codepoint-00.txt | |||||||||||||||||
| Progress and future development of Flow State Aware standards,and a proposal for alerting nodes or end-systems on data related to a flow | |||||||||||||||||
|
This document describes the work in progress on Flow State Aware standards activity in the ITU and proposes a new type of control packet to be identified that can alert downstream or upstream nodes on data related to an individual flow. | ||||||||||||||||
| draft-agl-tcpm-sadata-01.txt | |||||||||||||||||
| Faster application handshakes with SYN/ACK payloads | |||||||||||||||||
|
This document advocates the usage of small, mostly constant payloads in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show how this can have immediate benefits for some protocols. Additionally, we describe a new TCP option that enables a wider range of protocols to gain from it. | ||||||||||||||||
| draft-ahrenholz-hiprg-dht-03.txt | |||||||||||||||||
| HIP DHT Interface | |||||||||||||||||
|
This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. | ||||||||||||||||
| draft-akhter-bmwg-mpls-meth-04.txt | |||||||||||||||||
| MPLS Benchmarking Methodology | |||||||||||||||||
|
The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. | ||||||||||||||||
| draft-alexeitsev-bliss-alert-info-urns-01.txt | |||||||||||||||||
| Alert-Info header URNs for Session Initiation Protocol (SIP) | |||||||||||||||||
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. | ||||||||||||||||
| draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt | |||||||||||||||||
| RSVP-TE based impairments collection mechanism | |||||||||||||||||
|
The problem of path validation of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical impairments related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical impairments measured over optical nodes along the light-path. | ||||||||||||||||
| draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt | |||||||||||||||||
| Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment | |||||||||||||||||
|
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not Expires May 2009 [page 1] Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt address many issues that comes when a P2MP-TE LSP is signaled in a multi-domain networks. Specifically, one of the issues in multi-domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is remerge free. This document provides a framework and required protocol extensions needed for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. | ||||||||||||||||
| draft-ali-mpls-sig-pid-multiplexing-case-00.txt | |||||||||||||||||
| Signaled PID When Multiplexing Multiple Payloads over RSVP-TE LSPs | |||||||||||||||||
|
There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object Expires January 2009 [page 1] draft-ali-mpls-sig-pid-multiplexing-case-00.txt [RFC3471], [RFC3473]. The document propose use of some dedicated PID values to cover some typical cases of multiple payload carried by the LSP, including that indicates to the egress node to ignore signaling to learn payload carried by the LSP. | ||||||||||||||||
| draft-allan-mmrp-for-mac-in-mac-00.txt | |||||||||||||||||
| Simplified VPLS-PBB interworking via MMRP | |||||||||||||||||
|
This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. | ||||||||||||||||
| draft-allman-tcp-early-rexmt-07.txt | |||||||||||||||||
| Early Retransmit for TCP and SCTP | |||||||||||||||||
|
This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. | ||||||||||||||||
| draft-ananth-tcpm-persist-00.txt | |||||||||||||||||
| Clarification of sender behaviour in persist condition. | |||||||||||||||||
|
This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. | ||||||||||||||||
| draft-ananth-tsvwg-timewait-00.txt | |||||||||||||||||
| Effects of port randomization with TCP TIME-WAIT state. | |||||||||||||||||
|
Source port randomization has been suggested to provide improved security and obfuscation which helps in adding robustness towards blind attacks. With TCP in practice, simply producing a random port as the source port for a new connection can lead to problems when a TCP client establishes connections to a TCP server at a high rate. If the same source port value is chosen twice, the client TCP connection can fail due to the server having the Transmission Control Block (TCB) for this tuple lingering in TIME-WAIT state. This memo discusses the ramifications of such source port reuse scenarios and suggests some mitigations to avoid the same. | ||||||||||||||||
| draft-ancp-mc-extensions-00.txt | |||||||||||||||||
| Multicast Control Extensions for ANCP | |||||||||||||||||
|
This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs. | ||||||||||||||||
| draft-andreasen-sipping-rfc3603bis-07.txt | |||||||||||||||||
| Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture | |||||||||||||||||
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. | ||||||||||||||||
| draft-andrews-dnsext-expire-00.txt | |||||||||||||||||
| EDNS EXPIRE OPTION | |||||||||||||||||
|
Provide a method for slave DNS servers to honour the SOA EXPIRE field as if they were always transferring from the master, even when using other slaves to perform indirect transfers and refresh queries. | ||||||||||||||||
| draft-arberg-ancp-vendorspecific-01.txt | |||||||||||||||||
| Vendor Specific Message for ANCP. | |||||||||||||||||
|
This document is aimed at presenting Access Node Control Protocol (ANCP) with vendor specific protocol extensions. | ||||||||||||||||
| draft-arifumi-6man-rfc3484-revise-00.txt | |||||||||||||||||
| Things To Be Considered for RFC 3484 Revision | |||||||||||||||||
|
RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. | ||||||||||||||||
| draft-arkko-arp-iana-rules-05.txt | |||||||||||||||||
| IANA Allocation Guidelines for the Address Resolution Protocol (ARP) | |||||||||||||||||
|
This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. | ||||||||||||||||
| draft-arkko-eap-aka-kdf-10.txt | |||||||||||||||||
| Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') | |||||||||||||||||
|
This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. | ||||||||||||||||
| draft-arkko-p2pi-incentives-00.txt | |||||||||||||||||
| Incentives and Deployment Considerations for P2PI Solutions | |||||||||||||||||
|
Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to- peer traffic in networks in the most efficient way and with minimal impact to other traffic. This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic. The paper concludes that it is essential to understand the incentives in order to have a deployable solution. | ||||||||||||||||
| draft-arkko-townsley-coexistence-00.txt | |||||||||||||||||
| IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios | |||||||||||||||||
|
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. | ||||||||||||||||
| draft-asaeda-mboned-session-announcement-req-00.txt | |||||||||||||||||
| Requirements for IP Multicast Session Announcement in the Internet | |||||||||||||||||
|
The Session Announcement Protocol (SAP) [3] was used to announce information for all available multicast sessions to the prospective receiver in an experimental network. It is usefull and easy to use, but difficult to control the SAP message transmission in a wide area network. This document describes the several major limitations SAP has and the requirement of multicast session announcement in the global Internet. | ||||||||||||||||
| draft-asaeda-multimob-igmp-mld-mobility-extensions-01.txt | |||||||||||||||||
| IGMP and MLD Extensions for Mobile Hosts and Routers | |||||||||||||||||
|
This document describes IGMP and MLD protocol extensions for mobile hosts and routers. IGMP and MLD are necessary protocols for hosts to request join or leave multicast sessions. While the regular IGMP and MLD protocols support communication between mobile hosts and routers over wireless networks, this document discusses the conditions how mobile hosts and routers use IGMP and MLD in their communication more effectively. Aside from a modified protocol semantic, an optional "Listener Hold" function for the IGMP and MLD protocol is introduced, which requires an extended signaling. | ||||||||||||||||
| draft-asaeda-multimob-pmip6-extension-00.txt | |||||||||||||||||
| PMIPv6 Extensions for Multicast | |||||||||||||||||
|
This document describes Proxy Mobile IPv6 (PMIPv6) extensions and solutions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and establish a bi-directional tunnel to manage mobility for mobile nodes within the Proxy Mobile IPv6 domain. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. | ||||||||||||||||
| draft-asati-idr-bgp-bestpath-selection-criteria-00.txt | |||||||||||||||||
| BGP Bestpath Selection Criteria | |||||||||||||||||
|
BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. | ||||||||||||||||
| draft-asati-pim-multicast-routing-blackhole-avoid-00.txt | |||||||||||||||||
| Multicast Routing Blackhole Avoidance | |||||||||||||||||
|
This document specifies a mechanism to avoid blackholing of IP Multicast traffic due to the disruption of multicast tree during the time when the RPF neighbor is yet to become the PIM neighbor. Such scenario is possible during the topology change (e.g. link UP) in an IP network that employs PIM-SM (or SSM) as the multicast routing protocol and a unicast routing protocol (including static routing). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. | ||||||||||||||||
| draft-asveren-dime-cong-03.txt | |||||||||||||||||
| Diameter Congestion Signaling | |||||||||||||||||
|
Diameter base protocol defines the network layer functionality to be used by applications. This document adds hop-to-hop congestion notification mechanism to that functionality. | ||||||||||||||||
| draft-atarashi-netappmodel-01.txt | |||||||||||||||||
| The Model for Net and App Interaction | |||||||||||||||||
|
This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. | ||||||||||||||||
| draft-atlas-icmp-unnumbered-06.txt | |||||||||||||||||
| Extending ICMP for Interface and Next-hop Identification | |||||||||||||||||
|
This memo defines ICMP extensions, using ICMP multi-part messages, through which a router or host can explicitly identify an interface by ifIndex, name, and/or address, as already used in MIBs and by OSPF. The interfaces so identified can be the interface upon which an undeliverable datagram arrived, a sub-IP member of that interface, and the interface through which the datagram would have been sent. The nexthop IP address can also be provided as part of the outgoing interface information. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing. | ||||||||||||||||
| draft-badra-tls-express-01.txt | |||||||||||||||||
| TLS Express | |||||||||||||||||
|
This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. | ||||||||||||||||
| draft-bagnulo-behave-dns64-01.txt | |||||||||||||||||
| DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers | |||||||||||||||||
|
DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client- server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with NAT64. | ||||||||||||||||
| draft-bagnulo-behave-nat64-02.txt | |||||||||||||||||
| NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers | |||||||||||||||||
|
NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64, and gives suggestions on how they should be deployed. | ||||||||||||||||
| draft-bagnulo-savi-fcfs-00.txt | |||||||||||||||||
| First-Come First-Serve Source-Address Validation Implementation | |||||||||||||||||
|
This memo describes FCFS SAVI a mechanism to provide source address validation for IPv4 and IPv6 networks using the First-Come First- Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. | ||||||||||||||||
| draft-bagnulo-savi-send-00.txt | |||||||||||||||||
| SeND-based Source-Address Validation Implementation | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-bajko-v6ops-port-restricted-ipaddr-assign-02.txt | |||||||||||||||||
| Port Restricted IP Address Assignment | |||||||||||||||||
|
With the foreseen scarcity of public IPv4 addresses and the hesitation and technical difficulties to deploy IPv6, the transition scenarios which assumed that migration to IPv6 happens before the run-out of IPv4 addresses, need to be revisited. This document defines a method to allocate the same IPv4 address to multiple hosts, thus prolonging the availability of public IPv4 addresses for as long as it takes for IPv6 to take over the demand for IPv4. The document also describes the deployment scenarios where this method is applicable. | ||||||||||||||||
| draft-baker-behave-ivi-01.txt | |||||||||||||||||
| IVI Update to SIIT and NAT-PT | |||||||||||||||||
|
This note proposes an address and service architecture designed to facilitate transition from an IPv4 Internet to an IPv6 Internet. This service contains three parts: A DNS Application Layer Gateway, a stateful Network Address Translator that enables IPv6 clients to initiate connections to IPv4 servers and peers, and a stateless Network Address Translator that enables IPv4 and IPv6 systems to interoperate freely. It is couched as an update to RFCs 2765 and 2766. This is because the stateless service is essentially the SIIT with a different address format, and because the DNS Application Layer Gateway and the stateful translator have significant similarities to NAT-PT. There are, however, important differences from NAT-PT, responsive to the issues raised in RFC 4966. | ||||||||||||||||
| draft-baker-behave-v4v6-framework-00.txt | |||||||||||||||||
| Framework for IPv4/IPv6 Translation | |||||||||||||||||
|
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. | ||||||||||||||||
| draft-baker-behave-v4v6-translation-00.txt | |||||||||||||||||
| IP/ICMP Translation Algorithm | |||||||||||||||||
|
This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateful and a stateless mode. In the stateful mode, translation state is maintained between IPv4 address/transport/port tuples and IPv6 address/transport/port tuples, enabling IPv6 systems to open sessions with IPv4 systems. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment with neither state nor configuration in the translator. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Significant issues exist in the stateful mode that are not addressed in this document, related to the maintenance of the translation tables. This document confines itself to the actual translation. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. Some text had been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. The changes in this document reflect five components: 1. Updating references 2. Redescribing the network model to map to present and projected usage 3. Moving the address format to the framework document, to coordinate with other drafts on the topic 4. Some changes in ICMP. 5. Description of both stateful and stateless operation. | ||||||||||||||||
| draft-bakker-sipping-3gpp-ims-xml-body-handling-01.txt | |||||||||||||||||
| Specification of 3GPP IM CN Subsystem XML body handling | |||||||||||||||||
|
This document registers new disposition-types for the Content- Disposition header that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. | ||||||||||||||||
| draft-balus-l2vpn-vpls-802.1ah-03.txt | |||||||||||||||||
| VPLS Extensions for Provider Backbone Bridging | |||||||||||||||||
|
IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. | ||||||||||||||||
| draft-barnes-ecrit-rough-loc-01.txt | |||||||||||||||||
| Using Imprecise Location for Emergency Context Resolution | |||||||||||||||||
|
Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. | ||||||||||||||||
| draft-barnes-geopriv-lo-sec-03.txt | |||||||||||||||||
| Additional Location Privacy Considerations | |||||||||||||||||
|
This document discusses security and privacy concerns related to the distribution of location information over the Internet. We clarify how privacy rules can be enforced by a location server, and how privacy rules should be interpreted in store and forward networks. We also describe general mechanisms for providing end-to-end assurances about a location object. | ||||||||||||||||
| draft-barnes-healthy-food-00.txt | |||||||||||||||||
| Healthy Food and Special Dietary Requirements for IETF meetings | |||||||||||||||||
|
This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. | ||||||||||||||||
| draft-barnes-periodic-location-retrieval-00.txt | |||||||||||||||||
| Periodic Retrieval of Location Information by Devices and Location Information Servers | |||||||||||||||||
|
The base HTTP Enabled Location Delivery (HELD) protocol includes options for retrieving location information from a LIS by a Device. Some networks require the ability for the device to periodically request location information from the LIS and/or for the LIS to periodically request location information from the device. Extensions to base HELD allow a Device to establish a context with a LIS and negotiate capabilities of the Device in terms of providing location information. The measurement extensions to base HELD allow the LIS to request location information from a Device. This document provides an overview of the requirements and a solution using HELD and HELD extensions to support the periodic request of location information, both by a Device from an LIS and by the LIS from a Device, depending upon the specific scenario and measurement capabilities of the Device. | ||||||||||||||||
| draft-barnes-xcon-examples-00.txt | |||||||||||||||||
| Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples | |||||||||||||||||
|
This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. | ||||||||||||||||
| draft-barre-shim6-impl-01.txt,.ps | ||||||||||||||
| Shim6 Implementation Report : LinShim6 | ||||||||||||||
|
LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. | |||||||||||||
| draft-barreto-ietf-dhhmac-sas-00.txt | |||||||||||||||||
| MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode | |||||||||||||||||
|
This document presents a new transport mode to the Multimedia Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has as its objective the negotiation of cryptography parameters necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end multimedia channel, but all its operation modes have some kind of limitation that prevents it of being used to this purpose. The MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and MIKEY-DHHMAC modes by adding the features of key continuity and Short Authentication String (SAS), making possible its use in any end-to- end multimedia scenario. | ||||||||||||||||
| draft-barwood-dnsext-fr-resolver-mitigations-08.txt | |||||||||||||||||
| Resolver side mitigations | |||||||||||||||||
|
Describes mitigations against spoofing attacks on DNS, including: (1) Repeating the query, including techniques for handling non-deterministic responses. (2) Prepending a random nonce to the question where a referral is probable. (3) Estimating the entropy available, taking into account (a) Observed packets with incorrect IDs. (b) The content of the cache. | ||||||||||||||||
| draft-bauer-mext-aero-topology-00.txt | |||||||||||||||||
| ATN Topology Considerations for Aeronautical NEMO RO | |||||||||||||||||
|
The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document. | ||||||||||||||||
| draft-bberry-rfc4938bis-00.txt | |||||||||||||||||
| PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics | |||||||||||||||||
|
This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. | ||||||||||||||||
| draft-begen-fecframe-1d2d-parity-scheme-01.txt | |||||||||||||||||
| RTP Payload Format for Non-Interleaved and Interleaved Parity FEC | |||||||||||||||||
|
This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. | ||||||||||||||||
| draft-begen-mmusic-rfc4756bis-00.txt | |||||||||||||||||
| Forward Error Correction Grouping Semantics in Session Description Protocol | |||||||||||||||||
|
The Session Description Protocol (SDP) supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the semantics that were defined in RFC 4756 generally fail to provide the specific grouping relationships between the source and repair flows when there are more than one source and/or repair flows in the same group. Furthermore, the existing semantics also do not support additive repair flows and prioritization among the repair flows protecting one or more source flows. This document addresses these issues by introducing new FEC grouping semantics. | ||||||||||||||||
| draft-bellis-dnsext-dnsproxy-00.txt | |||||||||||||||||
| DNS Proxy Implementation Guidelines | |||||||||||||||||
|
This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network devices. | ||||||||||||||||
| draft-bellis-enum-send-n-02.txt | |||||||||||||||||
| IANA Registrations for the 'Send-N' Enumservice | |||||||||||||||||
|
This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. | ||||||||||||||||
| draft-bellovin-useipsec-10.txt | |||||||||||||||||
| Guidelines for Specifying the Use of IPsec Version 2 | |||||||||||||||||
|
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. | ||||||||||||||||
| draft-berger-mpls-gmpls-lsp-reroute-00.txt | |||||||||||||||||
| PathErr Message Triggered MPLS and GMPLS LSP Reroute | |||||||||||||||||
|
This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms and defines no new formats or mechanisms. It relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. | ||||||||||||||||
| draft-bernardos-autoconf-backbone-mesh-reqs-01.txt | |||||||||||||||||
| Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless Mesh Network scenarios | |||||||||||||||||
|
This Internet Draft presents the multi-hop Backbone Wireless Mesh Network scenario, summarising its basic characteristics and describing the requirements and desired properties of an IP Autoconfiguration mechanism aimed at being used in this kind of networks. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs and the IP autoconfiguration problem statement in MANETs, the WG is expected to start working on solutions. This document describes an ad-hoc scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for this Wireless Mesh environment. | ||||||||||||||||
| draft-bernardos-autoconf-evaluation-considerations-03.txt | |||||||||||||||||
| Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs | |||||||||||||||||
|
This Internet Draft aims at providing general guidelines for the AUTOCONF solution space, through providing a set of evaluation considerations for IP autoconfiguration mechanisms in MANETs. These evaluation considerations conform to the AUTOCONF problem statement draft and the MANET architecture draft. The main objective of this draft is to illustrate some key features and highlight some important behaviours for the different autoconf mechanisms, and thus aiming to help solution developers during mechanisms' design and to help implementers in the choice of the autoconf mechanism that fits better their particular requirements, taking into consideration a number of important factors that are discussed in this draft. | ||||||||||||||||
| draft-bernardos-autoconf-solution-space-02.txt | |||||||||||||||||
| Ad-Hoc IP Autoconfiguration Solution Space Analysis | |||||||||||||||||
|
This draft aims at analysing the solution space for the ad hoc IP autoconfiguration problem, based on the problem statement draft and the MANET architecture draft. Some evaluation considerations, are also taken into account. This draft classifies, at a generic level, the solution space of the possible approaches that could be followed to solve the IPv6 autoconfiguration for MANETs problem. The various approaches of IPv6 autoconfiguration for MANETs are illustrated, and the benefits and tradeoffs in different aspects of IPv6 autoconfiguration are explored. | ||||||||||||||||
| draft-bernardos-manet-autoconf-survey-04.txt | |||||||||||||||||
| Survey of IP address autoconfiguration mechanisms for MANETs | |||||||||||||||||
|
This Internet Draft provides a detailed description of most of the existing IP autoconfiguration solutions proposed so far. The main aim of this document is to serve as a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, showing their key characteristics, conforming to the AUTOCONF problem statement draft and the MANET architecture draft. Furthermore, each solution is analysed based on a number of evaluation considerations. | ||||||||||||||||
| draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt | |||||||||||||||||
| Analysis on how to address NEMO RO for Aeronautics Mobile Networks | |||||||||||||||||
|
The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the mobile network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the mobile network are not required to support any kind of mobility, since packets go through the Mobile Router-Home Agent (MRHA) bi- directional tunnel. Data packets belonging to communications of nodes of the mobile network have to traverse the Home Agent, and therefore resulting paths are likely to be suboptimal. Additionally, the solution adds packet overhead, due to the use of encapsulation between the Mobile Router and the Home Agent. There are currently a set of well defined NEMO Route Optimization requirements for Operational Use in Aeronautics and Space Exploration, which potential solutions should meet. This document analyses how the problem of NEMO RO for Aeronautics Mobile Networks might be tackled, in a way as generic as possible, trying to identify those open questions and deployment considerations that need to be addressed. The main goal of this document is to foster the discussion about aeronautics NEMO RO solution space within the MEXT WG. | ||||||||||||||||
| draft-bernardos-mext-miron-00.txt | |||||||||||||||||
| Mobile IPv6 Route Optimisation for Network Mobility (MIRON) | |||||||||||||||||
|
The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON enables mobility-agnostic nodes within the mobile network to directly communicate (i.e. without traversing the MRHA bi-directional tunnel) with Correspondent Nodes. The solution is based on the Mobile Router performing the Mobile IPv6 Route Optimisation signalling on behalf of the nodes of the mobile network. This document (in an appendix) also analyses how MIRON fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. | ||||||||||||||||
| draft-bernardos-mext-nemo-ro-cr-00.txt | |||||||||||||||||
| Correspondent Router based Route Optimisation for NEMO (CRON) | |||||||||||||||||
|
The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, based on the well-known concept of Correspondent Router. The solution aims at meeting the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Based on the ideas that have been proposed in the past, as well as some other extensions, this document describes a Correspondent Router based solution, trying to identify the most important open issues. The main goal of this first version of the document is to describe an initial NEMO RO solution based on the deployment of Correspondent Routers and trigger the discussion within the MEXT WG about this kind of solution. This document (in an appendix) also analyses how a Correspondent Router based solution fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. | ||||||||||||||||
| draft-bernstein-ccamp-wson-encode-01.txt | |||||||||||||||||
| Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks | |||||||||||||||||
|
A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMSPL routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. | ||||||||||||||||
| draft-bernstein-ccamp-wson-impairments-01.txt | |||||||||||||||||
| A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments | |||||||||||||||||
|
The operation of optical networks can require a level of detail in the characterization of network elements, subsystems, devices, and cabling not typically encountered with other networking technologies. In addition, these physical characteristics may be important to consider during typical day-to-day operations such as optical path establishment and connection monitoring, as well as during the network planning, installation, and turn-up phases. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with common control and measurement plane and path computation element technologies to support impairment aware Routing and Wavelength Assignment (RWA) in optical networks. | ||||||||||||||||
| draft-bernstein-ccamp-wson-info-03.txt | |||||||||||||||||
| Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks | |||||||||||||||||
|
This document provides an information model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of information described in this model is | ||||||||||||||||