TCP header compression for 6LoWPAN

This document describes LOWPAN_TCPHC, a scheme for compressing the header of Transmission Control Protocol (TCP) segments, in order to reduce the overhead on low-power and lossy networks. It also specifies the LOWPAN_TCPHC header fields for the transmission of TCP segments over IPv6 for Low-power Wireless Personal Area Networks (6LoWPAN). In many cases, the 20 bytes of the mandatory TCP header can be compressed into as little as 6 bytes.

-- draft-aayadi-6lowpan-tcphc

The Web Origin Concept

This document defines the concept of an "origin", which represents a web principal. Typically, user agents isolate content retrieved from different origins to prevent a malicious web site operator from interfering with the operation of benign web sites. In particular, this document defines how to compute an origin from a URI, how to serialize an origin to a string, and an HTTP header, named "Origin", for indicating which origin caused the user agent to issue a particular HTTP request.

-- draft-abarth-origin

This document provides RSVP-TE extensions to support Generalized Multi-Protocol Label Switching (GMPLS) control of Impairment Aware Routing and Wavelength Assignment in Wavelength Switched Optical Networks (WSONs).

-- draft-agraz-ccamp-wson-impairment-rsvp

MANET Address Configuration using Address Pool July 2010

This document describes an address configuration mechanism based on the concept of address pool allocation in the connected MANET. The Internet gateway acts as a DHCP (Dynamic Host Configuration Protocol) server and assigns not a single address but a part of its address pool to an address requesting node and, then, the node can assign a part of its own address pool to its neighbor nodes. By doing this, the address allocation procedure can be expedited.

-- draft-ahn-autoconf-addresspool

Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs

-- draft-ali-mpls-sig-pid-multiplexing-case

webm datagram

This document describes a combination and profiling of existing IETF protocols to provide a datagram service that is suitable as a generic transport substrate for the RTC-Web family of real-time audio/video applications.

-- draft-alvestrand-dispatch-rtcweb-datagram

Domain Name Data Escrow

This document specifies the format and contents of Data Escrow deposits for Domain Name Registration Organizations.

-- draft-arias-noguchi-registry-data-escrow

RFC3484 Revise

RFC 3484 has several known issues to be fixed. Deprecation of IPv6 site-local unicast address and the coming of ULA brought some preferable changes to the rules. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these points to be fixed and proposes possible useful changes to be included in the revision of RFC 3484.

-- draft-arifumi-6man-rfc3484-revise

Proxy Network Mobility Protocol

Proxy Mobile IPv6 (PMIPv6) provides the Internet connectivity to Mobile Node in a PMIPv6 domain. Current PMIPv6 specification supports only Host Mobility. In order to support a network mobility, this document defines Proxy Mobility Protocol that provides and maintains the connectivity for the Mobile Network Node (MNN) in the mobile network (nemo). This document discusses the deployment consideration of PNEMO and proposes the possible solution accordingly.

-- draft-arita-netext-pnemo

Scalable NATs

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space.

-- draft-arkko-dual-stack-extra-lite

IPv6-Only Experiences

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.

-- draft-arkko-ipv6-only-experience

IPv6 Transition Guidelines

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and recommends ones that have been found to work well in operational networks in many common situations.

-- draft-arkko-ipv6-transition-guidelines

IPv4 and IPv6 Co-Existence

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time, but hopefully also helps understand the rationale behind current IETF tools for co- existence and transition.

-- draft-arkko-townsley-coexistence

Explicit Membership Tracking Function

This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency).

-- draft-asaeda-mboned-explicit-tracking

Tuning the Behavior of IGMP and MLD

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, mainly for a query timer tuning.

-- draft-asaeda-multimob-igmp-mld-optimization

PMIPv6 Extensions for Multicast

This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes.

-- draft-asaeda-multimob-pmip6-extension

DHCP Relay Agent Configuration Option

This document defines a Dynamic Host Configuration Protocol (DHCP) Relay Agent Configuration option and associated machinery to configure the Relay Agent.

-- draft-asati-dhc-relay-agent-config

Routing Table Based Address Selection

RFC 3484 defines two algorithms for default source and destination address selection, but it has several shortcomings. This document specifies an alternate address selection algorithm that uses routing tables as policy input.

-- draft-axu-addr-sel

Additional Private IPv4

When a private network or internetwork grows very large it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered.

-- draft-azinger-additional-private-ipv4-space-issues

CIDR for IPv6

This document discusses strategies for assigning and aggregating IPv6 address space. While CIDR was created to help alleviate this problem in regards to IPv4 addresses with the original [RFC1519] (and updated in [RFC4632]) we are now in need of a similar document to give direction for IPv6 addressing policies. Similarly, [RFC1518] discussed how to use CIDR to allocate address space for IPv4, and [RFC1887] discusses the subject for IPv6. The objective here is to update these documents and provide the best current guidance on how to manage address space in conjunction with managing the growth of routing tables in an IPv6 world.

-- draft-azinger-cidrv6

Scalable Addressing for IPv6

This document presents a scalable architecture for assigning and aggregating IPv6 address space. The current IPv4 assignment and addressing architecture has been successful in helping to scale the IPv4 routing architecture. This same architecture, when carried forward to IPv6, will help to ensure that the IPv6 routing architecture is sustainable.

-- draft-azinger-scalable-addressing

Mobile IPv6 and Dual-stack Mobile IPv6 require the signaling between the mobile node and home agent to be secured. However security for the user plane is optional and is a choice left to the mobile node. This document proposes extensions to Mobile IPv6 signaling which Security On Demand Oct 25, 2010 enables the user plane traffic to be secured on a demand basis. The mobile node or the home agent can request at any time security for the user plane traffic. Security for user plane traffic can be triggered as a result of policy or mobility or user's choice.

-- draft-bajko-mext-sod

This document defines an IPv4 DHCP Option and related methods to allocate the same IPv4 address to multiple nodes by sharing the available port space. These options can be used in the context of port range-based solutions (port range delegation) or NAT-based ones (port delegation or port forwarding).

-- draft-bajko-pripaddrassign

Testing Eyeball Happiness

The amount of time it takes to open a session using common transport APIs in dual stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably open sessions quickly in a complex environment such as dual stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it.

-- draft-baker-bmwg-testing-eyeball-happiness

Internet Protocols for the Smart Grid

This note identifies the key protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.

-- draft-baker-ietf-core

It takes too long...

A barrier to the deployment of IPv6 is the amount of time it takes to open a session using common transport APIs. This note addresses issues and requests solutions that may respond to them.

-- draft-baker-v6ops-session-start-time

LCP Policy URIs

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules.

-- draft-barnes-geopriv-policy-uri

Extended IPv6 Addressing

This document discusses an extension of the algorithmic translation between IPv4 and IPv4-translatable IPv6 addresses. The extended address format contains transport-layer port range information which allows several IPv6 nodes to share a single IPv4 address with each node managing a different range of ports. This address format extension can be used for IPv4/IPv6 translation, as well as IPv4 over IPv6 tunneling.

-- draft-bcx-address-fmt-extension

PPETP

This document describes PPETP (Peer-to-Peer Epi-Transport Protocol) a peer-to-peer distribution protocol suited for streaming applications over networks made of heterogeneous nodes.

-- draft-bernardini-ppetp

MANET autoconf survey

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. Furthermore, each solution is analysed based on a number of evaluation considerations.

-- draft-bernardos-manet-autoconf-survey

PMIPv6 flow mobility

Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility management protocol that enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing their IP addresses. PMIPv6 basic specification also provides limited multi- homing support to multi-mode mobile devices. The ability of movement of selected flows from one access technology to another is missing in basic PMIPv6. This document describes enhancements to the Proxy Mobile IPv6 protocol that are required to support flow mobility over multiple physical interfaces.

-- draft-bernardos-netext-pmipv6-flowmob

Mesh Under IPv6 Routing Requirements

Wireless mesh routing for low cost wireless mesh devices can be done at a layer under IPv6. This document examines the functional requirements of this kind of routing and to explore why this approach might be used in some contexts. It should be noted that this kind of routing is orthogonal to IP-level routing; there is no inherent conflict between the two.

-- draft-beroset-ietf-1hop-routing-reqs

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value. However, it presents no backward compatible way for incrementally introducing new IPv6 extension headers inside the network. Additionally since there is no standard format for extension headers, it becomes impossible for intermediaries that want to deep inspect the packet to parse an incoming packet which carries an extension header that it does not recognize. This document attempts to standardize the IPv6 extension header format to fix these issues.

-- draft-bhatia-6man-update-ipv6-ext-hdr

Currently a few routing protocols use IPSec for authenticating their protocol packets. There are known issues with using IPSec with the routing protocols and this draft proposes an alternative Generic Authentication mechanism that can be used so that these protocols do not depend upon IPSec for security. The mechanism introduced in this draft is generic and can be used by any protocol that currently uses IPSec for authentication. While this mechanism is generic, this draft specifically looks at OSPFv3 and how it can use the mechanism described herein.

-- draft-bhatia-karp-non-ipsec-ospfv3-auth

Auth Trailer for OSPFv3

Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication.

-- draft-bhatia-manral-auth-trailer-ospfv3

SAVI mix

This document reviews how multiple address discovery methods can coexist in a single savi device and collisions are resolved when the same binding entry is discovered by two or more methods.

-- draft-bi-savi-mix

snmp cfg

This document defines a collection of YANG definitions for configuring SNMP engines.

-- draft-bjorklund-netmod-snmp-cfg

Explicit Signaling Target MRM

The standard operation of the General Internet Signaling Transport (GIST) Protocol uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. This specification proposes an Explicit Signaling Target Message Routing Method (EST-MRM) to allow for transmission of signaling messages to explicit targets. While the PC-MRM implicitly addresses signaling nodes by an interception method, the EST-MRM allows to explicitly address signaling nodes.

-- draft-bless-nsis-est-mrm

RBridges: OAM Support

The IETF has standardized RBridges, devices that implement the TRILL protocol, a solution for transparent shortest-path frame routing in multi-hop networks with arbitrary topologies, using a link-state routing protocol technology and encapsulation with a hop-count. As RBridges are deployed in real-world situations, operators will need tools for debugging problems that arise. This document specifies a set of RBridge features for operations, administration, and maintenance purposes in RBridge campuses. The features specified in this document include tools for traceroute, ping, and error reporting.

-- draft-bond-trill-rbridge-oam

Support for hosts in MANETs

This document describes how hosts using IPv6 Stateless Address Autoconfiguration can be used in a MANET, without a need for any change, neither in functioning of Neighbor Discovery nor in MANET protocols. In addition, legacy hosts nor other parts of the network are faced any deviation on the IPv6 Addressing architecture.

-- draft-boot-autoconf-support4hosts

6lowpan-ghc

This short I-D provides a complete design for a simple addition to 6LoWPAN Header Compression that enables the compression of generic headers and header-like payloads.

-- draft-bormann-6lowpan-ghc

CoAP-misc

This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, CoAP.

-- draft-bormann-coap-misc

A64 DNS Record

In the context of IPv4-IPv6 interconnection (or interworking), several solutions have been proposed within IETF. Some of these solutions require the definition of a new IPv4-Embedded IPv6 address which is used to represent an IPv4-only host in an IPv6 realms and the definition of a new mechanism called DNS64 for synthesizing a AAAA record, representing an IPv4-Embedded IPv6 address in the DNS system, from the A record representing the IPv4 address of the IPv4- only host . This IPv4-Embedded IPv6 address, when managed by a translator, is to be considered as "fake" address in a DNS system since it is not necessarily assigned to any host's interface qualified by the associated name. This document defines a new DNS record type and query type to identify IPv4-Embedded IPv6 address from native IPv6 ones. The new record type and query type aim at helping the requesting party to enforce its policies and avoid crossing NAT64 boxes when possible. Native addresses are to be preferred.

-- draft-boucadair-behave-dns-a64

SDP Alternate Connectivity Attribute

This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax.

-- draft-boucadair-mmusic-altc

AFTR Bypass Procedure

This document proposes a solution to avoid the use of two stateful DS-Lite AFTR devices when both end-points are located behind different AFTR devices. For this purpose a new IPv6 extension header, called Tunnel Endpoint Extension Header (TEEH), is defined. The proposed procedure encourages the use of IPv6 between DS-Lite AFTR nodes as a means to avoid the unnecessary crossing of AFTR devices. A Flow Label based solution is also described.

-- draft-boucadair-softwire-cgn-bypass

Extended DS-lite

Dual-Stack lite requires that the AFTR must have IPv4 connectivity. This forbids a service provider who wants to deploy AFTR in an IPv6- only network. This memo proposes an extension to implement a stateless IPv4-in-IPv6 encapsulation in the AFTR so that AFTR can be deployed in an IPv6-only network.

-- draft-boucadair-softwire-dslite-v6only

PCP DHCP Options

This document specifies DHCP (IPv4 and IPv6) Options to convey the IP address or a FQDN of a PCP Server. A dedicated option to prevent overloading PCP Servers is also specified.

-- draft-bpw-pcp-dhcp

UPnP IGD-PCP Interworking Function

This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP interworking function. An UPnP IGD-PCP Interworking function is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP is used in the LAN side and PCP in the external side of the CP router.

-- draft-bpw-pcp-upnp-igd-interworking

PCP Flow Examples

This document provides a set of examples to illustrate PCP operations. It is a companion document to the base PCP specification.

-- draft-bpw-softwire-pcp-flow-examples

RPL Applied to Home/Building Environments

The purpose of this document is to to provide guidance in the use of RPL to provide the features required in building or home environments, two application spaces which share a substantial number of requirements. Note that this document refers to a specific revision of the RPL draft, and thus, a new revision of the RPL draft will likely necessitate a new revision of this document.

-- draft-brandt-roll-rpl-applicability-home-building

Mobility and Privacy

Choices in Internet mobility architecture may have profound effects on privacy. This draft revisits this issue, stresses its increasing importance, and makes recommendations.

-- draft-brim-mobility-and-privacy

Re-ECN: Adding Accountability to TCP/IP

This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion, but these are described more fully in a companion document.

-- draft-briscoe-tsvwg-re-ecn-tcp

Multicast in GI-DS-lite

This document discusses multicast deployment aspects for networks which leverage Gateway-Initiated Dual-Stack lite.

-- draft-brockners-softwire-mcast-gi-ds-lite

Packet PW

This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.

-- draft-bryant-pwe3-packet-pw

draft-c1222-transport-over-ip-07.txt

This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/ MC12.22 Advanced Metering Infrastructure (AMI) Application-Layer Messages on an IP network.

-- draft-c1222-transport-over-ip

ALG Problem Statement

Application Layer Gateway (ALG) has been widely implemented and used to support address and port translation in the payload for some well- known protocols. Due to the lackness of standardization on addressing ALG related issues, a number of serious problems are faced by service deployments and upgrades. This document specifies the common problems for ALG in various aspects. In addition, some collected feedbacks are also listed as the next steps to tackle these problems.

-- draft-cao-alg-problem-statement

TCP HC

The document specifies a TCP compression header for low-power and lossy networks.

-- draft-cao-lwip-tcp-hc

MIF Solution Analysis

This document analyzes whether the problems encountered by a multi- homed host are satisfactorily addressed by mechanisms currently implemented in operating systems.

-- draft-cao-mif-analysis

PW to LSP Binding

A bidirectional Pseudowire (PW) service currently uses two unidirectional PWs each carried over a unidirectional LSP. Each end point of a PW or segment of multi-segment PW (MS-PW) independently selects the LSP to use to carry the PW for which it is the head end. Some transport services may require that bidirectional PW traffic follows the same paths through the network in both directions. Therefore, PWs may be required to use LSP with congruent paths. Bidirectional LSPs or co-routed associated unidirectional LSPs allow this service to be provided. This document specifies some extensions to LDP that allow both ends of a PW (or segment of a MS-PW) to select and bind to the same bidirectional LSP or use unidirectional LSPs with congruent paths.

-- draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp

Flow Label Update

Various published proposals for use of the IPv6 flow label are incompatible with its existing specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document proposes changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility.

-- draft-carpenter-6man-flow-update

Flow Label for tunnel ECMP/LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for tunneled traffic.

-- draft-carpenter-flow-ecmp

Referral Requirements

The purpose of a referral is to enable a given entity in a multiparty Internet application to pass information to another party. It enables a communication initiator to be aware of relevant information of its destination entity before launching the communication. This memo discusses the problems involved in referral scenarios.

-- draft-carpenter-referral-ps

SAMPLE NAT traversal

IPv6 deployment is delayed by the existence of millions of subscriber network address translators (NATs) that cannot be upgraded to support IPv6. This document specifies a mechanism for traversal of such NATs. It is based on an address mapping and on a mechanism whereby suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via a stateless server, known as a SAMPLE server, operated by their Internet Service Provider. SAMPLE is an alternative to the Teredo protocol.

-- draft-carpenter-softwire-sample

Monitoring MPLS Label Mappings

Because one MPLS label only identifies one single flow on a link between two MPLS routers, information related to one MPLS label is exchanged only between (physically and logically) neighbour routers. In other words, MPLS label have a link-local significance on which two neighbour routers have previously agreed on. It is therefore not a trivial task for a network operator to know where a flow is going as it implies to retreive the MPLS labels mappings on each hops in order to get a complete view of end-to-end LSP paths. This taks is even harder when it comes to get the MPLS label mappings over time in a purpose of monitoring and/or troubleshooting network services. This document thus defines a new method to monitor MPLS label mappings that collects and stores MPLS labels mapping information so as to offer to one IP/MPLS network operator a reliable and clear view of its network LSPs end-to-end establishment over time while minimising the impact on network convergence and router CPU.

-- draft-cauchie-opsawg-monitoring-mpls-label-mapping

draft-cavuto-dtcp-03.txt

Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server.

-- draft-cavuto-dtcp

DMM-PS

Mobility solutions deployed with centralized mobility anchoring in existing hierarchical mobile networks are more prone to the following problems or limitations compared with distributed and dynamic mobility management: (1) Routing via a centralized anchor is often longer, so that those mobility protocol deployments that lack optimization extensions results in non-optimal routes, affecting performance; whereas routing optimization may be an integral part of a distributed design. (2) As mobile network becomes more flattened centralized mobility management can become more non-optimal, especially as the content servers in a content delivery network (CDN) are moving closer to the access network; in contrast, distributed mobility management can support both hierarchical network and more flattened network as it also supports CDN networks. (3) Centralized route maintenance and context maintenance for a large number of mobile hosts is more difficult to scale. (4) Scalability may worsen when lacking mechanism to distinguish whether there are real need for mobility support; dynamic mobility management, i.e., to selectively provide mobility support, is needed and may be better implemented with distributed mobility management. (5) Deployment is complicated with numerous variants and extensions of mobile IP; these variants and extensions may be better integrated in a distributed and dynamic design which can selectively adapt to the needs. (6) Excessive signaling overhead should be avoided when end nodes are able to communicate end-to-end; capability to selectively turn off signaling that are not needed by the end hosts will reduce the handover delay. (7) Centralized approach is generally more vulnerable to a single point of failure and attack often requiring duplication and backups, whereas a distributed approach intrinsically mitigates the problem to a local network so that the needed protection can be simpler.

-- draft-chan-distributed-mobility-ps

DMM-PS

PMIP and LISP are both network-based. Integration of PMIP with a hierarchical design into the LISP network provides network-based fast-mobility support to enable a mobile node to perform handover in both LISP and non-LISP networks, and non-optimal PMIP routes in the LISP network are avoided.

-- draft-chan-lisp-pmip

ECC PK and sig. support in CGA and SEND

This draft describes a mechanism to deploy Elliptic Curve Cryptography (ECC) alongside with Cryptographically Generated Addresses (CGA) and the Secure Neighbor Discovery (SEND). This document provides basic skeleton to integrate new signature algorithms in CGA and SEND.

-- draft-cheneau-csi-ecc-sig-agility

Signature Algorithm Agility in SEND

This document describes a mechanism to enable the Secure Neighbor Discovery (SEND) protocol to select between different signature algorithms to use with Cryptographically Generated Addresses (CGA).

-- draft-cheneau-csi-send-sig-agility

IPv4-Embedded IPv6 Routing

This document describes routing packets destined to IPv4-Embedded IPv6 addresses across IPv6 transit core using OSPFv3 with a separate routing table.

-- draft-cheng-ospf-ipv4-embedded-ipv6-routing

Implementation Techniques

Since small devices such as sensors are often required to be physically small and inexpensive, an implementation of the Internet protocols will have to deal with having limited computing resources and memory. This report describes the design and implementation of a small TCP/IP stack called lwIP that is small enough to be used in minimal systems.

-- draft-chen-lwip-implementataion

6PE MIB

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 a MIB module for IPv6 Provider Edge Routers (6PE)over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs).

-- draft-chen-mpls-6pe-mib

P2MP LSP Egress Protection

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

-- draft-chen-mpls-p2mp-egress-protection

GACH Based Path Association

This document defines a mechanism to bind two unidirectional LSPs into an associated bidirectional LSP and perform related operations, including update, withdrawal and verification of the association without a control plane. This is achieved using Generic Associated Channel.

-- draft-chen-mpls-tp-bidir-lsp-association

OSPF Abnormal State

This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain.

-- draft-chen-ospf-abnormal-state-info

Intelligent OSPF LSDB Exchange

This document presents an intelligent database exchange mechanism for the database exchange procedure in OSPFv2 and OSPFv3. This mechanism is backward compatible. It eliminates the unnecessary database exchanges through using the existing reachability information calculated from the link state database and the un-reachability information about routers recorded. It significantly speeds up the establishment of the full adjacency between two routers in some situations.

-- draft-chen-ospf-intelligent-db-exch

Find Backup Egress

This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress.

-- draft-chen-pce-compute-backup-egress

Find Backup Ingress

This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress.

-- draft-chen-pce-compute-backup-ingress

discovery-llmnr

The memo has recommended to deploy Link-Local Multicast Name Resolution (LLMNR) in PCP scenarios. Depending on that, it could not only avoid adherence to DNS during PCP server name resolving, but also company with PCP FQDN DHCP options extension to accomplish PCP server discovery. In order to fit LLMNR into PCP network, particular LLMNR deployment guides and relevant configurations are considerated along with PCP elements installation.

-- draft-chen-pcp-discovery-llmnr

NAT64-CPE

The document has proposed an approach of NAT64-CPE mode, which would give residential service opportunities to be accessed by remote subscribers going through IPv6 networks. The document captures the fundamental NAT64 functionalities with special cares to fit into CPE scenarios and don't need cooperate with DNS64 any more. It will compatible with legacy residential servers and no further updates requirements to DNS.

-- draft-chen-v6ops-nat64-cpe

DNS-Based Service Discovery

This document describes a convention for naming and structuring DNS resource records. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this convention allows clients to discover a list of named instances of that desired service, using standard DNS queries. In short, this is referred to as DNS-based Service Discovery, or DNS-SD.

-- draft-cheshire-dnsext-dns-sd

Multicast DNS

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server can be useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

-- draft-cheshire-dnsext-multicastdns

Replacement of AppleTalk NBP

One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. The views expressed in this Informational document represent the opinions of the authors, not IETF consensus.

-- draft-cheshire-dnsext-nbp

The Ad Hoc Configuration Protocol

The Ad Hoc Configuration Protocol is a protocol for automatically configuring nodes in a multihop mesh network. It is designed to replace DHCPv4, DHCPv6 and IPv6 Router Advertisements in networks where these protocols are difficult or impossible to deploy.

-- draft-chroboczek-ahcp

The Babel Routing Protocol

Babel is a mostly loop-free distance vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.

-- draft-chroboczek-babel-routing-protocol

Internet-Draft

This document specifies the IP Flow Information Export (IPFIX) protocol specific to the Mediation.

-- draft-claise-ipfix-mediation-protocol

Cloud Log

This document provides an open and extensible log format to be used by any cloud entity or cloud application to log and trace activities that occur in the cloud. It is equally applicable for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services. CloudLog is defferent in content, but not in nature from the traditional logging as it takes in account transient nature of identities and resources in the cloud.

-- draft-cloud-log

NETCONF Transaction Test

This document extends the capabilities of the NETCONF configuration management protocol in order to standardize mechanisms to perform sets of active tests (i.e., verification) against servers' running configuration to afford the client and server a more robust and resilient configuration management capability. Specifically, this document defines a transaction test module based upon the defined set of Uniform Resource Locators. The transaction tests in this module are executed by the NETCONF verify operation.

-- draft-cole-netconf-transaction

Rapid acquisition of subscription

A new proposal is presented for speeding up the acquisition by the MAG of the MN's active multicast subscription information, in order to accelerate the multicast delivery to the MN during handover. To do that, an extension of the current PMIPv6 protocol is required. The solution described in this memo is not only applicable to the base multicast solution, but also it can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, it is also independent of the role played by the MAG within the multicast metwork (either acting as MLD proxy or multicast router).

-- draft-contreras-multimob-rams

Lumas

A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire.

-- draft-cordell-lumas

DAD-Proxy

The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one.

-- draft-costa-6man-dad-proxy

Network Capacity

This document defines the metric of network capacity, including link capacity aspect, router capacity aspect and path capacity aspect. RFC5136 has defined link capacity and path capacity, where the router impact is implicitly considered in link capacity. However, in this document, router capacity is considerred as a separate factor of path capacity, no longer a factor of link capacity. This document explicitly describes the router capacity and its impact to network capacity, e.g. how to evaluate path capacity. This document is derived from RFC5136 and obsoletes RFC5136.

-- draft-cui-ippm-rfc5136bis

pcp subscriber identification

This document analyzes on PCP security problems related with subscriber identification, such as denial-of-service(DoS), unwanted deleting of mappings, man-in-the-middle(MITM), and stale mapping problem. Then several solutions are proposed.

-- draft-cui-pcp-subscriber-identification

B4-translated DS-lite

The well known Dual Stack lite (DS-lite) technology does great contribution to the deployment of IPv6 and alleviate the shortage of IPv4 address by making it possible to share a single IPv4 address between many hosts. However, the original DS-lite model make AFTR the bottleneck of whole system, thus AFTR's efficiency limits the capability of whole DS-lite model. This draft proposes a B4- translated Ds-lite to alleviate the burden of AFTR so that AFTR is able to serve more B4s.

-- draft-cui-softwire-b4-translated-ds-lite

4over6 Access

This draft proposes a mechanism for bidirectional IPv4 communication between IPv4 Internet and end hosts or IPv4 networks sited in IPv6 access networks. This mechanism follows the softwire hub & spoke model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. By allocating public IPv4 addresses to end hosts/networks in IPv6, it can achieve IPv4 end-to-end bidirectional communication between IPv4 Internet and these hosts/networks. This mechanism is an IPv4 access method for hosts and IPv4 networks sited in IPv6.

-- draft-cui-softwire-host-4over6

Translation Spot Negotiation

IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence techniques, roughly divided into the categories of tunneling and translation. Tunneling and translation have respective application scopes, and translation has some technical limitations, including scalability issue, application layer translation, operation complexity, etc. To improve the availability of translation, this draft proposes the method of selecting appropriate translation spot to execute translation. When the translation spot is not on IPv4-IPv6 border, tunnel is used to achieve the traversing between translation spot and IP border. This method applies well in mesh scenario where both IPv4 and IPv6 client network exists, and BGP can be extended to achieve a translation spot signaling.

-- draft-cui-softwire-pet

October 2010

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in 3GPP and provides inter-system mobility policies and access network specific information to the mobile nodes(MNs).

-- draft-das-mipshop-andsf-dhcp-options

DHCPv6 Route Option

This document describes DHCPv6 Route Options for provisioning IPv6 routes on nodes with DHCPv6 clients. This is expected to improve the ability of an operator to configure and influence a node's ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical.

-- draft-dec-dhcpv6-route-option

RADIUS Extensions

The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit attribute type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems.

-- draft-dekok-radext-radius-extensions

LwIP PS

Since small devices such as sensors are often required to be physically small and inexpensive, an implementation of the Internet protocols will have to deal with having limited computing resources and memory. This report describes the design and implementation of a small TCP/IP stack called lwIP that is small enough to be used in minimal systems.

-- draft-deng-lwip-ps

Naming IPv6 address parts

In the daily communication between technicians, engineers and other people who need to deal with computer networks, it is often necessary to refer to particular parts of IP addresses. In the world of IPv4, the term "octet" is well established, however as the use of IPv6 is spreading, it becomes apparent that there is no such commonly accepted term for IPv6 addresses. Discussing and explaining technical matters become difficult when different people use different terms for the same thing. Therefore, this document discusses several naming proposal for those 16bit pieces of IPv6 addreses.

-- draft-denog-v6ops-addresspartnaming

IPv4 Residual Deployment(4rd)

During the long transition period from IPv4-only to IPv6-only, networks will have not only to deploy the IPv6 service but also to maintain some IPv4 connectivity for a number of customers, and this for both outgoing and incoming connections and for both customer- individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. It applies not only to ISPs have IPv6-only routing networks, but also to those that, during early transition stages, have IPv4-only routing, with 6rd to offer the IPv6 service, those that have dual- stack routing networks but with private IPv4 addresses assigned to customers. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4 which achieve better IPv4-address sharing ratios (but at a price of significantly higher operational complexity).

-- draft-despres-softwire-4rd

Native IPv6 behind NAT44 CPEs (6a44)

Most CPEs should soon be dual stack, but a large installed base of IPv4-only CPEs is likely to remain for several years. Also, with the IPv4 address shortage, more and more ISPs will assign private IPv4 addresses to their customers. The need for IPv6 connectivity therefore concerns hosts behind IPv4-only CPEs, including such CPEs that are assigned private addresses. The 6a44 mechanism specified in this document addresses this need, without limitations and operational complexities of Tunnel Brokers and Teredo to do the same. 6a44 is based on an address mapping and on a mechanism whereby suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via a stateless 6a44 server function operated by their Internet Service Provider. With it, IPv6 traffic between two 6a44 hosts in a single site remains within the site. Except for IANA numbers that remain to be assigned, the specification is intended to be complete enough for running codes to be independently written and interwork.

-- draft-despres-softwire-6a44

Native-IPv6 across NAT44s (6rd+)

The [6rd] mechanism permit IPv6 "rapid deployment" across IPv4 infrastructures of Internet Service Providers, but only in cases where customer-premise equipments can be upgraded to support it. 6rd+ extends this IPv6 rapid deployment capability to hosts behind customer-premise equipments that cannot be upgraded (provided these hosts can be upgraded themselves to support 6rd+). Like [6rd], 6rd+ provides native IPv6 addresses, so that quality of service can be guaranteed by Internet Service Providers; it operates statelessly, which ensures simplicity and scalability; and it transmits encapsulated IPv6 packets along optimized paths, which contributes to efficiency and acceptability.

-- draft-despres-softwire-6rdplus

Stateless Address Mapping (SAM)

Stateless Address Mapping (SAM) is a generic mechanism to statelessly establish tunnels, point-to-multipoint, for packets of an address family that traverse domains whose routing is in another address family (mesh softwires). It extends tunneling principles of [6rd] to other address-family combination than IPv6 across IPv4 domains. It thus introduces, for a variety of use cases, a simpler mesh-softwire model than that of [RFC5565]. Among SAM use cases, some are solutions to previously unsolved problems: native IPv6 across IPv4 NATs, with optimized paths; multihoming with independent CPEs and provider-aggregatable prefixes; public IPv4 addresses across IPv6-only domains with optimized paths; static sharing of IPv4 addresses, without impact on routing information bases.

-- draft-despres-softwire-sam

ISIS BND

There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of Boundary Node (BN)Discovery information within an IS-IS area or within the entire IS-IS routing domain.

-- draft-dhody-pce-bn-discovery-isis

OSPF BND

There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of Boundary Node (BN) Discovery information within an OSPF area or within the entire OSPF routing domain.

-- draft-dhody-pce-bn-discovery-ospf

Design for a Nameserver Control Protocol

This document presents a design for a nameserver control protocol (NSCP). A common data model for describing the configuration and operation of a basic, but usable, generic name server is defined. This is expressed in a formal modeling language (YANG) and can be used as the basis of a set of NETCONF operations and capabilities. The data model described is extensible and will allow for the creation of additional capabilities, ensuring that the protocol can support all the features of a name server.

-- draft-dickinson-dnsop-nameserver-control

SAVI for PANA

This document analysis the source address vilidation in PANA with slacc,and specifies the procdure for binding assigned address to the UE through PANA related mechanism.

-- draft-ding-savi-pana-with-slacc

BGP Based VPN Route Constrain

There are some problems with current RT-Constrain mechanism defined in RFC 4684. Firstly, the IPv6 address specific Route Target defined in [RFC5701] cannot be accommodated in current RT membership NLRI. Secondly, the distribution of RT-Constrain information cannot build correct VPN distribution graph when hierarchical route reflection (RR) is used. Thirdly, current RT-Constrain mechanism is used for filtering of all kinds of VPN services and can result in imprecise VPN route distribution when multiple VPN services are deployed in the network. This document describes the above problems in detail and proposes solutions for these problems. A generalized RT-Constrain mechanism is defined to accommodate the IPv6 address specific Route Target and to precisely control propagation of different kinds of VPN routing information. The proposed solution avoids unnecessary advertising and receiving of VPN routes when multiple VPN services are deployed. This document also proposes modifications of advertisement rules of RT- Constrain information to ensure the integrity of VPN distribution graph.

-- draft-dong-idr-vpn-route-constrain

Designation of PLRs in TE FRR

This document defines RSVP-TE extensions which enable the ingress node to designate particular LSRs along the path as Points of Local Repair (PLRs) of the protected LSP, and further indicate the protection type of each PLR. These mechanisms could enhance the control over the establishment of backup LSPs, achieve more flexible TE FRR and also could save the resources needed for establishing and maintaining unnecessary backup LSPs.

-- draft-dong-mpls-rsvp-te-plr-designation

IPv6 CGA Extension Header

This document specifies an IPv6 extension header called the Cryptographically Generated Address (CGA) Extension Header. The CGA Extension Header holds the CGA parameters associated with the source CGA of an IPv6 packet. This information can be used to validate that a particular packet was sent by the node associated with a specific CGA, enabling secure IPv6 address-based access control mechanisms.

-- draft-dong-savi-cga-header

NAT444 impacts

NAT444 is an IPv4 extension technology being considered by Service Providers to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Large-Scale NAT ("LSN") in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications.

-- draft-donley-nat444-impacts

dslite-flowlabel

This document extends the use of Dual-Stack Lite to identify discrete traffic flows using the IPv6 Flow Label. The identification of discrete traffic flows allows for the application of Quality of Service (QoS) classification and prioritization of traffic traversing Dual-Stack Lite tunnels.

-- draft-donley-softwire-dslite-flowlabel

An IPv4 Flowlabel Option

This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.

-- draft-dreibholz-ipv4-flowlabel

SCTP Mobility with RSerPool

This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).

-- draft-dreibholz-rserpool-applic-mobility

DHCPv6 IANA Rules

This document modifies the IANA rules for some DHCPv6 (Dynamic Host Configuration Protocol for IPv6) registries.

-- draft-droms-dhc-dhcpv6-iana

Reputation Reporting Protocol

This draft specifies a protocol for reporting various events associated with IP addresses. These events can be collected and aggregated to form a database containing information about the reputation of IP addresses.

-- draft-dskoll-reputation-reporting

draft-dt-roll-p2p-rpl-02

Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria.

-- draft-dt-roll-p2p-rpl

Internet facing server logging

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet facing servers log port number and accurate timestamps in addition to the incoming IP address.

-- draft-durand-server-logging-recommendations

NTTDM

Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing and handling of the TTs. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE).

-- draft-dzis-nwg-nttdm

IANA Considerations for NLPIDs

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA Considerations.

-- draft-eastlake-nlpid-iana-considerations

IRO

This memo specifies an improved alternate route optimization procedure for Mobile IPv6 designed specifically for environments where IPsec is used between peers (most probably with IKE). The replacement of the complex Return Routability procedure for a simple mechanism and the removal of HAO and RH2 extensions from exchanged packets result in performance and security improvements.

-- draft-ebalard-mext-ipsec-ro

m6t

MIPv6 [RFC3775] protocol has been designed to work on IPv6 networks: nothing was initially provisioned in the specification to support movement of Mobile Nodes to IPv4-only networks (with or without NAT) or the communication with IPv4 peers. DSMIPv6 [RFC5555] is the official solution specified to address those needs. It requires IPv4/NAT-awareness by the MIPv6 module, IKE module and IPsec stack. The global approach selected by DSMIPv6 requires changes to implementations and increases complexity. This memo presents an alternative approach to support operations of MIPv6 mobile nodes from IPv4-only networks. It does not require changes to MIPv6 modules, IKE module and IPsec stack.

-- draft-ebalard-mext-m6t

MIGRATE

This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and shows how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IPsec/IKE in a Mobile IPv6 environment. This document is heavily based on a previous draft [MIGRATE] written by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply reuses the MIGRATE mechanism defined in the expired document, removes a companion extension (SADB_X_EXT_PACKET) based on implementation feedback (complexity, limitations, ...) and fills the gap by very simple changes to MIGRATE mechanism. This results in a more simple and consistent mechanism, which also proved to be easier to implement. This document is expected to serve as a continuation of [MIGRATE] work. For that reason, the name of the extension has been kept. PF_KEY MIGRATE message serves as a carrier for updated information for both the in-kernel IPsec structures (Security Policy Database / Security Association Database) and those maintained by the key managers. This includes in-kernel Security Policy / Security Association endpoints, key manager maintained equivalents, and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements.

-- draft-ebalard-mext-pfkey-enhanced-migrate

IETF Management Framework

This document gives an overview of the IETF standard management framework and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand the document can be used as an overview and guideline by other SDOs or bodies planning to use IETF management technologies and data models.

-- draft-ersue-opsawg-management-fw

udp-checksum

We address the problem of computing the UDP checksum on tunneling IPv6 packets when using lightweight tunneling protocols.

-- draft-eubanks-chimento-6man

LISP Canonical Address Format (LCAF)

This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System.

-- draft-farinacci-lisp-lcaf

Hierarchical IPv4 Framework

This document describes a framework how the current IPv4 address space can be divided in two new address categories; a core address space (Area Locators, ALOC) that is globally unique and an edge address space (Endpoint Locators, ELOC) that is regionally unique - in the future the ELOC space is only significant in a private network or in a service provider domain, therefore a 32 x 32 bit addressing scheme and a hierarchical routing architecture is achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet; it also discusses a method to decouple the location and identifier functions, future applications can make use of the separation. The framework requires extensions to the existing Domain Name System, the existing IPv4 stack of the endpoints, middleboxes and to routers in the Internet. The framework can be implemented incrementally to endpoints, DNS, middleboxes and routers.

-- draft-frejborg-hipv4

DHCPv6 Address Selection Policy Opt

This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior.

-- draft-fujisaki-6man-addr-select-opt

RSVP-TE for LSP Boundary Control

[RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN). [RFC4206] introduces a region boundary determination algorithm and a Hierarchy LSP (H-LSP) creation method. However, in some scenarios, some attributes have to be attached with the boundary nodes in order to explicit control the hierarchy LSP creation. This document extends GMPLS signaling protocol for the requirement of explicit control the hierarchy LSP creation.

-- draft-fuxh-ccamp-boundary-explicit-control-ext

IPv4 Extension

IPv4 addresses are running out. I aim to create an extension to IPv4 that will allow organizations to migrate to a larger address space without the need to replace all existing IPv4 devices and software.

-- draft-gams-ipv4-extension

CGA MIB

This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA).

-- draft-garcia-martinez-cgamib

SEND MIB

This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol.

-- draft-garcia-martinez-sendmib

Abbreviated Title

When discussing deployment matters related to IPv6, a first hurdle which is encountered is the lack of common terminology or at least basic terms used in various fora. As a contribution in this area, this document identifies and proposes a set of terms and their definitions.

-- draft-garneij-ipv6-deployment-terminology

BFD Express Path

In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) have become (or are becoming) as (or more) critical to data path selection than other metrics. This document describes extensions to the BFD protocol, such that network performance information can be gathered in a scalable fashion, and subsequently used (by other protocols) to make path selection decisions. These extensions will also provide granular performance monitoring information.

-- draft-giacalone-bfd-express-path

draft-gnawali-roll-minrank-hysteresis-of

Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG).

-- draft-gnawali-roll-minrank-hysteresis-of

Flow Label Security

This document discusses the security implications of the IPv6 "Flow Label" header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets.

-- draft-gont-6man-flowlabel-security

EID Option to Obsolete Status

This document recommends that the IPv6 Endpoint Identification (EID) option (hex value 0x8a) be moved to Obsolete status.

-- draft-gont-6man-obsolete-eid-option

Teredo routing loops

Recently, a number of routing loop vulnerabilities were discovered in Teredo. This document specifies a number of security checks to be performed by Teredo hosts and Teredo servers such that these vulnerabilities are eliminated.

-- draft-gont-6man-teredo-loops

Generation of TCP timestamps

This document discusses the generation of TCP timestamps. In particular, it discusses a number of algorithms for producing monotonically-increasing timestamps such that timestamps can be used to reduce the TIME-WAIT state, and an algorithm for generating timestamps that allows for extended SYN-cookies.

-- draft-gont-timestamps-generation

Deprecation of ICMP Source Quench

This document formally deprecates the use of ICMP Source Quench messages by transport protocols.

-- draft-gont-tsvwg-source-quench

PCEP Ext for Reserv of Resources in PCE

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A limited form of statefulness is useful to improve PCE functionality in situations in which the local TED might not be up to date, or in the case of concurrent requests where most of the LSPs are computed before the end of the set-up of the LSPs when the TED is updated. The PCE can retain some context from the resources assigned to Path Requests during a certain period of time, so that it avoids suggesting the use of the same resources for subsequent TE LSPs. This document proposes an extension to the PCEP protocol to allow the PCC to request the PCE to block or reserve the resources computed in a path request of a TE LSP for subsequent requests for a certain time.

-- draft-gonzalezdedios-pce-reservation-state

draft-goyal-roll-p2p-measurement-01

This document specifies a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node in a low power and lossy network, thereby allowing the node to decide if it wants to initiate the discovery of a more optimal route.

-- draft-goyal-roll-p2p-measurement

swift

The swift is a generic multiparty (swarming) transport protocol. The TCP, today's dominating transport protocol, is connection/ conversation-oriented. But traffic-wise, the currently dominating usecase is content dissemination. There is a multitude of incompatible approaches to resolve that discrepancy above/below the transport layer: peer-to-peer, CDN, caches, mirrors, multicast, etc. The swift aims at creating a single unified content-centric transport protocol serving as a lingua-franca of content distribution. To implement that ultimate data cloud model, the protocol has to unify use cases of data download, video-on-demand and live streaming. It must work in the settings of client-server, peer-to-peer, CDN or peer-assisted networks, effectively blending those architectures.

-- draft-grishchenko-ppsp-swift

Geo-Location extensions in MRT

This document extends the Border Gateway Protocol (BGP) MRT export format for routing information to include terrestrial coordinates.

-- draft-grow-geomrt

Overlapping IPv4 Address Support

There are number of deployment scenarios where there is a need for a home agent to allocate the same private IPv4 address to multiple mobile nodes that it is serving. A service provider hosting home agent service for enterprises, or for supporting some of the IPv6 transitioning solutions related to IPv4 address exhaust problem, a home agent may have to allocate the same private IPv4 address to multiple mobile nodes. The Dual-stack Mobile IPv6 does not have such support. This document specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPv4 address assignment support.

-- draft-gundavelli-mext-dsmip-ipv4-overlap

Proxy Mobile IPv6 for WLAN Networks

Proxy Mobile IPv6 is a network-based mobility management protocol. The protocol is designed for providing mobility management support to a mobile node, without requiring its participation in any IP mobility related signaling. The base protocol is defined in an access technology independent manner, it identifies the general requirements from the link-layer for supporting the protocol operation. However, it does not provide any specific details on how it can be supported on a specific access technology. This specification identifies the key considerations for supporting Proxy Mobile IPv6 protocol on the widely deployed wireless LAN access architectures, based on IEEE 802.11 standards. It explores the current dominant wireless LAN deployment models and provides the needed interworking details.

-- draft-gundavelli-netext-pmipv6-wlan-applicability

Unicast Transmission on Link-layer

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link- layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address.

-- draft-gundavelli-v6ops-l2-unicast

draft-guo-radext-softwire-concentrator-00

6rd and DS-Lite are two most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. Both mechanisms need to configure the softwire concentrator information on the host. In many networks, the information may be stored in AAA servers while user configuration is mainly through DHC protocol. This document defines several RADIUS attributes that carries softwire concentrator information.

-- draft-guo-radext-softwire-concentrator

IPv6 Host Configuration in 6rd

This document proposes a new DHCPv4 option containing the addresses of DHCPv6 servers through which the 6rd CPE could obtain the IPv6 addresses of DHCPv6 servers. Thus, the 6rd CPE as a DHCP relay agent could relay DHCP messages from IPv6 hosts which is located in 6rd home networks to one of the known DHCPv6 servers.

-- draft-guo-softwire-6rd-ipv6-config

October 2010

6rd is One of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The DHCP 6rd option has been defined to configure 6rd CPE. But in many networks, the configuration information may be stored in AAA servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a RADIUS attribute that carries 6rd configuration information from AAA server to BNG.

-- draft-guo-softwire-6rd-radius-attrib

draft-guo-softwire-sc-discovery-04

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.

-- draft-guo-softwire-sc-discovery

Privacy Terminology

This memo introduces terminology for the main privacy aspects. The prime goal is to avoid situations where different interpretations of the same key privacy aspects result in different requirements when designing specific solutions, thus leading to an unnecessary confusion.

-- draft-haddad-alien-privacy-terminology

ALIen Problem Statement

This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement.

-- draft-haddad-alien-problem-statement

ALIen

This memo describes privacy threats related to the MAC and IP layers identifiers in a mobile and multi-homed environment.

-- draft-haddad-alien-threat-model

MIPv6 RO Mode Optimization

This memo describes an enhancement to Mobile IPv6 route optimization mode which is derived from introducing a social dimension within the home network.

-- draft-haddad-mext-mobisoc

IPv6 EDIT

There will be IPv4-only applications that remain in use as network managers begin deploying IPv6-only networks, or turning off IPv4 in the exiting dual-stack networks. These applications require a dual- stack capable host operating system, but that OS may find that the local network has not provided on-link IPv4 provisioning or routing support for the resulting packets. Skepticism that this situation will exist is widespread; because it is easy to ignore the costs someone else will incur and focus on the local situation. Taking the system level viewpoint, that skepticism makes no sense when it is widely acknowledged that people will resist replacing something that is working, particularly when the reason it might artificially stop is due to 'someone else's problem'. The reality of IPv4-only applications persisting in an IPv6-only provisioned network is specifically ignored by RFC 4038. This document deals with the situation by defining a new tunneling type for use within the edge or leaf network to the border where it interconnects with an IPv4 routing domain. The draft is being discussed on the ipv6@ietf.org list.

-- draft-hain-ipv6-edit

IPv6 FWRH

This document specifies a routing header for use by firewalls to enforce routing symmetry. The draft is being discussed on the ipv6@ietf.org list.

-- draft-hain-ipv6-fwrh

IPv6 RPF ICMP

This document specifies an icmp error message for use when the IPv6 source address has failed a reverse-path-forwarding (RPF) check. The draft is being discussed on the ipv6@ietf.org list.

-- draft-hain-ipv6-rpf-icmp

IPv6 ULA-C

This document defines Centrally Allocated IPv6 Unique Local address prefixes. These prefixes are globally unique and are intended for local communications, usually within a single network administration. They are not intended to be used in place of Provider Independent (PI) address prefixes available from the Regional Internet Registries (RIR) , and should not appear in the global routing table for the Internet. The draft is being discussed on the ipv6@ietf.org list.

-- draft-hain-ipv6-ulac

DNS Packet Layer Security

A mechanism for encrypting and authenticating communication between a DNS Client and server is presented. The mechanism is designed to compliment use of DNSSEC in the case where DNSSEC validation is performed at the resolver and it is not desirable to repeat validation at the server.

-- draft-hallambaker-dpls

Information Services Using SIP

Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers.

-- draft-haluska-sipping-directory-assistance

BIAv2

-- draft-hamarsheh-behave-biav2

SNMP on Constrained Devices

Simple Network Management Protocol (SNMP) is a widely deployed application protocol for network management and in particular network monitoring. This document describe the applicability of SNMP to constrained devices, e.g., nodes in Low-power and Lossy Networks. We discuss SNMP implementation techniques and we provide deployment considerations. Our discussion also covers the applicability of MIB modules to constrained devices.

-- draft-hamid-6lowpan-snmp-optimizations

Methodology for Content-Aware Devices

The purpose of this document is to define a set of test scenarios which may be used to create a series of statistics that will help to better understand the performance of network devices that operate at nework layers above IP. More specifically, these scenarios are designed to most accurately predict performance of these devices when subjected to modern traffic patterns. This document will operate within the constraints of the Benchmarking Working Group charter, namely black box characterization in a laboratory environment.

-- draft-hamilton-bmwg-ca-bench-meth

OSPF Analysis

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide.

-- draft-hartman-ospf-analysis

OTV

In today's networking environment most enterprise networks span multiple physical sites. Overlay Transport Virtualization (OTV) provides a scalable solution for L2/L3 connectivity across different sites using the currently deployed service provider and enterprise networks. It is a very cost-effective and simple solution requiring deployment of a one or more OTV functional device at each of the enterprise sites. This solution is agnostic to the technology used in the service provider network and connectivity between the enterprise and the service provider network. This document provides an overview of this technology.

-- draft-hasmit-otv

HIPLS

The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment.

-- draft-henderson-hip-vpls

MANET Autoconf Proposal (YAAP)

This document describes automatic configuration of MANET router interfaces, as well as prefix delegation to MANET routers. This autoconfiguration protocol is characterized by (i) adhering strictly to the Internet addressing architecture, (ii) being able to configure both MANET interface addresses and handle prefix delegation, and (iii) being able to configure both stand-alone MANETs, as well as MANETs connected to an infrastructure providing, e.g., globally scoped addresses/prefixes for use within the MANET.

-- draft-herberg-autoconf-yaap

CPE Enhancements for v6ops

Smart metering deployments in residential settings introduce the prospects of ad-hoc deployment of internetworked IPv6 customer premise equipment (CPE). WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs.

-- draft-herbst-v6ops-cpeenhancements

Virtual interface for mif

The usage of multiple interfaces in a host causes other problems due to the multiplicity of available interfaces. If interface is changed during communication, the communication is disrupted. Multiple interfaces in a host do not support the simultaneous usage of multiple interfaces. In this document, we discuss how to solve the problems of interface change and simultaneous usage of multiple interfaces and propose a virtual interface which hides the multiple interfaces from the IP stack of host. And we describe the applicability of virtual interface into the problem of multiple interfaces in multiple interfaces PS document. This document provides the implementation guidelines of virtual interface for a multiple interface host.

-- draft-hong-mif-virtual-interface

Hybrid Home Network Prefix

Proxy Mobile IPv6 (PMIPv6) supports multihoming where a mobile node can connect to a PMIPv6 domain through multiple interfaces for simultaneous access or inter-technology handoff. However, for an inter-technology handoff, PMIPv6 does not allow simultaneous access since all the home network prefixes associated with one interface are delivered to another interface of a mobile node. In addition, if we assume that the flow is classified by home network prefix, then the PMIPv6 cannot support flow mobility since it requires moving just some home network prefixes between interfaces. In this document, we propose a hybrid home network prefix assignment (HHNPA) scheme where both the static prefix model and the dynamic prefix model are used. By using these two different home network prefix models, it can support flow mobility that some home network prefixes are moved to another interface and some home network prefixes are remained at existing interface.

-- draft-hong-netext-hybrid-hnp

Scenarios of HNP on Logical interface

A logical interface is used to hide the existence and the change of physical interface from the IP layer of a host and it also can be used for a multiple interfaces mobile node in PMIPv6 domain. If a LMA assigns multiple home network prefixes to a multiple interfaces mobile node with a logical interface, there are various usages of multiple home network prefixes on the logical interface. As following general PMIPv6 operations described in RFC 5213, all multiple home network prefixes are shown to the IP layer. Also, the logical interface hides the existence of multiple home network prefixes and shows only one home network prefix to host IP layer. And in a LMA point of view, a LMA may acknowledge each physical interface or only logical interface of a mobile node when a multiple interfaces mobile node utilizes the logical interface. In this internet draft, we describe various scenarios of the usage of multiple home network prefixes on a logical interface.

-- draft-hong-netext-scenario-logical-interface

Dual-Path Mtrace

Mtrace2 is a tool that can be used to discover the path a multicast packet takes to reach one or more receivers. This document describes an enhancement to extend mtrace2 to be able to discover more than one path for a single (S,G) or (*,G) entry and to trace more than one (S,G) or (*,G) entries simultaneously. Changes to the mtrace2 protocol, and behaviors required by multicast routers to support the changes, are specified in this document.

-- draft-hou-dp-mtrace

Reverse DNS in IPv6 for ISPs

In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers.

-- draft-howard-isp-ip6rdns

PCN Data Collection

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 regular reports of PCN-defined measurements to a decision point. It requires further that the decision point occasionally be able to request certain measurements from ingress nodes. The decision point can be located in different places in the network. This memo defines a Diameter application to support communications between the ingress and egress nodes and a Diameter server acting as a PCN decision point.

-- draft-huang-dime-pcn-collection

Broadband Network Use Case

This document describes a use case for the migration from IPv4 to IPv6 for one of the typical broadband networks. The contant is orgnized by various scenarios we can foresee during the migration.

-- draft-huang-v6ops-v4v6tran-bb-usecase

Flow label use cases

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label, and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised.

-- draft-hu-flow-label-cases

RPL Headers

Routing for Low Power and Lossy Networks (RPL) is a routing protocol designed for Low power and Lossy Networks (LLNs). RPL includes routing information in IPv6 data plane datagrams to help maintain the routing topology. When forwarding a datagram into a RPL domain, a RPL router may need to expand the datagram to include routing information in IPv6 Extension headers. A generic solution has been defined that uses IP-in-IP tunneling to include RPL routing information. This document describes an alternative to inserting and removing RPL information in datagrams without the use of IP-in-IP tunneling.

-- draft-hui-6man-rpl-headers

Trickle Multicast Forwarding

Low power and Lossy Networks (LLNs) are typically composed of resource constrained nodes communicating over links that have dynamic characteristics. Memory constraints coupled with temporal variations in link connectivity makes the use of topology maintenance to support IPv6 multicast challenging. This document describes the use of Trickle to efficiently forward multicast messages without the need for topology maintenance.

-- draft-hui-6man-trickle-mcast

IP Multiple Connections

Current multiple interfaces terminal causes the problem of selecting a proper interface for a specific application, and this is a new question which will change the previous internet model. This document proposes a solution which extend DHCPv4 to carry the policy routing to map the IP flows to multiple interfaces.

-- draft-hui-mif-dhcpv4-routing

Fast Handover for Multicast

This document specifies the predictive fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Necessary extensions are specified for Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to support multicast handover procedure.

-- draft-hui-multimob-fast-handover

Service Flow identifier

This document proposes extensions to Proxy Mobile IPv6 that allows service flow identification and binding, and PMIP tunnels will be set up based on the service flow granularity. Therefore, multiple service flows of the mobile node can be separately controlled, e.g. QoS, charging, traffic control, and provides the precondition of flow mobility among multiple interfaces of the mobile node.

-- draft-hui-netext-service-flow-identifier

LISP MPLS Trans

This document proposes an LISP trans solution in MPLS network, provides a new LISP data encapsulation with two layer MPLS label and simplifies the IP-in-IP encapsulation by cutting of the outer IP header when LISP technology deploys in the MPLS network, the outer label is used for data forwarding, and the inner label is used to indicate the LISP data packet and carry the RLOC address information. In additional, three deployment scenarios are provided in this document..

-- draft-hu-lisp-mpls-trans

TARASeptember

This draft outlines a new routing architecture which I like to call TARA = Topology Aggregating Routing Architecture. Its primary objective is to eliminate the so-called scalability problem as proclaimed by RFC4984. By overcoming the true causes of this problem - which are indeed some holy routing paradigms - it may serve as the base for much better routing.

-- draft-hummel-tara

IPv6CP Extensions

The IPv6 Control Protocol (IPv6CP) is one of Network Control Protocols(NCPs) that are defined by the Point-to-Point Protocol(PPP) for establishing and configuring different network protocols. This document extends the IPv6CP for negotiating and configuring IPv6 network parameters over PPP links, including IPv6 address, IPv6 prefix, primary and alternative DNS server addresses.

-- draft-hu-pppext-ipv6cp-extensions

October 2010

The IPv6 Control Protocol (IPv6CP) is a NCP that allows for the negotiation of parameters for an IPv6 interface over PPP. In IPv6 networks, PPP (PPPoE) will still be an important mechanism for connecting broadband access users. However, IPv6CP only defines the Interface-Identifier option, other parameters such as IPv6 Address, Primary and alternative DNS server addresses, and delegated prefix have to be configured by other methods rather than IPv6CP. This document describes problems the ISPs faced and lists requirements related when deploying IPv6 in broadband access network over PPP.

-- draft-hu-pppext-ipv6cp-requirements

ICE-microLite

This document proposes a mechanism for conveying multiple IP addresses of different address families (e.g., IPv4, IPv6) for a given medium, in the same Session Description Protocol (SDP) offer. This proposed mechanism solves the backward compatibility which exists with ANAT, due to its syntax, and provides a migration path towards support for ICE. The proposed mechanism is significantly less complex then ICE or ICE-Lite but uses ICE syntax. The mechanism described in this document has been named ICE-microLite.

-- draft-hutton-mmusic-icemicrolite

Design Considerations for Extensions

This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved. Case study examples are included. It is intended to assist designers of both base protocols and extensions.

-- draft-iab-extension-recs

IDN Encodings

This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a canonical format and how complicated it ends up being as a result of using different encodings today.

-- draft-iab-idn-encoding

Evolution of the IP Model

This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, and especially properties which were (and at times still are) incorrectly perceived to exist, as well as properties that would cause problems if changed. Finally, it provides some guidance to protocol designers and implementers.

-- draft-iab-ip-model-evolution

LISP Map-Versioning

This document describes the LISP Map-Versioning mechanism. This is mechanism to provide in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modification of the mappings used to encapsulate packets. Note that, in the LISP encapsulation and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism.

-- draft-iannone-lisp-mapping-versioning

6LoWPAN Compression of IPv6 Datagrams

This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.

-- draft-ietf-6lowpan-hc

ND Optimization for LLNs

The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks.

-- draft-ietf-6lowpan-nd

6LoWPAN Routing Requirements

6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPAN networks, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions, but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing, which can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPAN, such as the IETF ROLL WG.

-- draft-ietf-6lowpan-routing-requirements

6LoWPAN Design and Applications

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document.

-- draft-ietf-6lowpan-usecases

Address Selection Considerations

Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to configure and potentially dynamically change RFC 3484 policy from a central control point, and for (nomadic) hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined.

-- draft-ietf-6man-addr-select-considerations

IPv6 extension headers

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers.

-- draft-ietf-6man-exthdr

Flow Label for tunnel ECMP/LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for tunneled traffic.

-- draft-ietf-6man-flow-ecmp

Flow Label Update

Various published proposals for use of the IPv6 flow label are incompatible with its existing specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document proposes changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility.

-- draft-ietf-6man-flow-update

IPv6 Node Requirements RFC 4294-bis

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.

-- draft-ietf-6man-node-req-bis

IPv6 prefixlen p2p

On inter-router point-to-point links, it is useful for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This document specifies motivation and usages of 127-bit IPv6 prefix lengths on inter-router point-to-point links.

-- draft-ietf-6man-prefixlen-p2p

RFC3484 Revise

RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects.

-- draft-ietf-6man-rfc3484-revise

RPL Option

The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain.

-- draft-ietf-6man-rpl-option

RPL Source Route Header

In Low power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining at most a few routes. In some configurations, it is necessary to use these memory constrained routers to deliver datagrams to nodes within the LLN. The Routing for Low Power and Lossy Networks (RPL) protocol can be used in some deployments to store most, if not all, routes on one (e.g. the Directed Acyclic Graph (DAG) root) or few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL domain.

-- draft-ietf-6man-rpl-routing-header

IPv6 UDP Checksum Considerations

This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints.

-- draft-ietf-6man-udpzero

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 a 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.

-- draft-ietf-alto-protocol

ALTO Requirements

Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. 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 guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations, and it solicits feedback and discussion.

-- draft-ietf-alto-reqs

ANCP Multicast Extensions

This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification.

-- draft-ietf-ancp-mc-extensions

Token-Based Port Mapping

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service attacks that could be used to cause one or more RTP packets to be sent to a victim client.

-- draft-ietf-avt-ports-for-ucast-mcast-rtp

Rapid Acquisition of RTP Sessions - RAMS

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem.

-- draft-ietf-avt-rapid-acquisition-for-rtp

Choosing an RTCP CNAME

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates these guidelines to allow endpoints to choose unique RTCP CNAMEs.

-- draft-ietf-avt-rtp-cnames

EKT SRTP

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.

-- draft-ietf-avt-srtp-ekt

DNS64

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.

-- draft-ietf-behave-dns64

IPv6-to-IPv4 FTP

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch.

-- draft-ietf-behave-ftp64

TURN Extension for IPv4/IPv6 transition

This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address).

-- draft-ietf-behave-turn-ipv6

BIH

This document describes the "Bump-In-the-Host" (BIH), a host based IPv4 to IPv6 protocol translation mechanism that allows a subset of applications supporting only IPv4 to communicate with peers that are reachable only with IPv6. A host may be connected to IPv6-only or dual-stack access network. Essentially BIH makes the IPv4 applications think they talk to IPv4 peers and hence hides the existence of IPv6 from those applications. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's [RFC3338], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations. This document combines and updates both [RFC2767] and [RFC3338]. The changes in this document reflect five components 1. Supporting IPv6 only network connections 2. IPv4 address pool use private address instead of the unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 3. Extending ENR and address mapper to operate differently 4. Adding an alternative way to implement the ENR 5. Going for standards track instead of experimental/ informational

-- draft-ietf-behave-v4v6-bih

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-ietf-behave-v6v4-framework

IPv4/IPv6 Translation

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC2765.

-- draft-ietf-behave-v6v4-xlate

Stateful NAT64

This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The public IPv4 address can be shared among several IPv6-only clients. When the stateful NAT64 is used in conjunction with DNS64 no changes are usually required in the IPv6 client or the IPv4 server.

-- draft-ietf-behave-v6v4-xlate-stateful

BFD MIB

This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol.

-- draft-ietf-bfd-mib

BFD MIB

This draft defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations.

-- draft-ietf-bfd-tc-mib

IGP Convergence Benchmark Methodology

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.

-- draft-ietf-bmwg-igp-dataplane-conv-meth

IGP Convergence Benchmark Terminology

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.

-- draft-ietf-bmwg-igp-dataplane-conv-term

Benchmarking Terminology for

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP-Layer with protection may be provided at the Sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). Protection Performance

-- draft-ietf-bmwg-protection-term

Reset Characterization

An operational forwarding device may need to be re-started (automatically or manually) for a variety of reasons, an event that we call a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation. This document specifies a methodology for characterizing reset (and recovery time) during benchmarking of forwarding devices, and provides clarity and consistency in reset test procedures beyond what's specified in RFC2544. It therefore updates RFC2544.

-- draft-ietf-bmwg-reset

draft-ietf-ccamp-assoc-info-00.txt

The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. The document also reviews how the association is to be provided in the context of GMPLS recovery. No new new procedures or mechanisms are defined with respect to GMPLS recovery.

-- draft-ietf-ccamp-assoc-info

General Network Element Constraint EncodingDecember 2010

Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.

-- draft-ietf-ccamp-general-constraint-encode

draft-ietf-ccamp-gmpls-ted-mib-07.txt

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.

-- draft-ietf-ccamp-gmpls-ted-mib

draft-ietf-ccamp-lsp-hierarchy-bis-08

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle TE links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. The mechanisms defined in this document deprecates the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206.

-- draft-ietf-ccamp-lsp-hierarchy-bis

November 19, 2010

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.]

-- draft-ietf-ccamp-mpls-tp-cp-framework

Resource Sharing Remote Id

The RSVP ASSOCIATION object allows to create association across RSVP path states or across Resv states. Two association types are currently defined: recovery and resource sharing. This document defines a new association type called "Resource Sharing Remote Identification". It can be used by the sender to convey to the receiver the information that can then be used by the receiver to identify a downstream initiated resource sharing association.

-- draft-ietf-ccamp-rsvp-resource-sharing

Constrained Application Protocol (CoAP)

This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.

-- draft-ietf-core-coap

draft-ietf-csi-dhcpv6-cga-ps-06.txt

This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function. As an informational document, this document aims to analyze the possible interactions between CGAs and DHCPv6 from the functional perspective. This document does NOT propose/define any concrete solutions. Whether these possibilities are going to be defined as solutions or standards in the future is out of scope.

-- draft-ietf-csi-dhcpv6-cga-ps

SEND Hash Threat Analysis

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND.

-- draft-ietf-csi-hash-threat

Secure Proxy ND Support for SEND

Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending a ND message is the owner of the address from which the message is sent and/or posses a key which authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation.

-- draft-ietf-csi-proxy-send

SEND certificate profile and management

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.

-- draft-ietf-csi-send-cert

SEND Name Type Registry

SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKI).

-- draft-ietf-csi-send-name-type-registry

DCCP-UDP Encapsulation

This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes.

-- draft-ietf-dccp-udpencap

Relay Agent Encapsulation for DHCPv4

This document describes a general mechanism whereby DHCP relay agents can encapsulate DHCP packets that they are forwarding in the direction of DHCP servers, and decapsulate packets that they they are forwarding toward DHCP clients, so that more than one relay agent can insert relay agent suboptions into the forwarding chain.

-- draft-ietf-dhc-dhcpv4-relay-encapsulation

LDRA

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions.

-- draft-ietf-dhc-dhcpv6-ldra

Relay-Supplied DHCP Options

This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary.

-- draft-ietf-dhc-dhcpv6-relay-supplied-options

DUID-UUID

This document defines a new DHCPv6 Unique Identifier (DUID) type, called DUID-UUID. DUID-UUIDs are derived from the already standardized UUID format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP.

-- draft-ietf-dhc-duid-uuid

PD Exclude Option

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation.

-- draft-ietf-dhc-pd-exclude

The Relay Agent Id Suboption

This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

-- draft-ietf-dhc-relay-id-suboption

draft-ietf-dhc-secure-dhcpv6-01.txt

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs.

-- draft-ietf-dhc-secure-dhcpv6

Virtual Subnet Selection Options

This memo defines a Virtual Subnet Selection (VSS) option for each of DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay- agent-information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942].

-- draft-ietf-dhc-vpn-option

Diameter Applications Design Guidelines

The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules.

-- draft-ietf-dime-app-design-guide

dime-extended-naptr

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanism do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node in order to discover which one supports a required application. This document describes an improvement using an extended format for the Straightfoward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand.

-- draft-ietf-dime-extended-naptr

Diameter IKEv2 PSK

The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared secrets. With [RFC 5778] the Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared secret based authentication available with IKEv2. This document therefore extends the functionality offered by [RFC 5778] with pre-shared key based authentication offered by IKEv2 when no EAP is used.

-- draft-ietf-dime-ikev2-psk-diameter

Diameter NAT Control Application

This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes.

-- draft-ietf-dime-nat-control

PMIP6 Localized Routing Support

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by 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 localized routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol.

-- draft-ietf-dime-pmip6-lr

Diameter Base Protocol

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations.

-- draft-ietf-dime-rfc3588bis

Diameter NASREQ

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

-- draft-ietf-dime-rfc4005bis

DNS IANA Considerations

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.

-- draft-ietf-dnsext-5395bis

EDNS0 Extensions

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification (RFC2671) based on 10 years of deployment experience.

-- draft-ietf-dnsext-rfc2671bis-edns0

DNAME Redirection

The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision.

-- draft-ietf-dnsext-rfc2672bis-dname

AS112 Nameserver Operations

Many sites connected to the Internet make use of IPv4 addresses that are not globally-unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation.

-- draft-ietf-dnsop-as112-ops

Locally-served DNS Zones

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics.

-- draft-ietf-dnsop-default-local-zones

draft-drinks-spprov

This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model and an XML Schema Document.

-- draft-ietf-drinks-spprov

Trustworthy Location Information

For some location-based applications, such as emergency calling or roadside assistance, it is important to be able to determine whether location information is trustworthy. This document outlines potential threats to trustworthy location and analyzes the operational issues with potential solutions.

-- draft-ietf-ecrit-trustworthy-location

Unauthenticated Emergency Service

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, however, the device does not have these credentials for network access, does not have a VoIP service provider, 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.

-- draft-ietf-ecrit-unauthenticated-access

EAP-CHBIND

This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem.

-- draft-ietf-emu-chbind

IANA Registration for IAX Enumservice

This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761.

-- draft-ietf-enum-iax

FEC Framework Config Signaling

FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s).

-- draft-ietf-fecframe-config-signaling

ForCES LFB Library

This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). It is defined according to ForCES FE model [RFC5812] and ForCES protocol [RFC5810] specifications. These basic LFB classes are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. Descriptions of individual LFBs are presented and detailed XML definitions are included in the library. Several use cases of the defined LFB classes are also proposed.

-- draft-ietf-forces-lfb-lib

FTP HOST Command for Virtual Hosts

This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

-- draft-ietf-ftpext2-hosts

Internet Location Architecture

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.

-- draft-ietf-geopriv-arch

Geopriv DHCP Location URI Option

This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI) of a client, which can be dereferenced in a separate transaction by the client or an entity the client sends this URI to.

-- draft-ietf-geopriv-dhcp-lbyr-uri-option

HELD Identity

When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address. Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted.

-- draft-ietf-geopriv-held-identity-extensions

Location Measurements

A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

-- draft-ietf-geopriv-held-measurements

DHCP Option for Coordinate LCI

This document specifies Dynamic Host Configuration Protocol Options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values.

-- draft-ietf-geopriv-rfc3825bis

BGP Monitoring Protocol

This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol.

-- draft-ietf-grow-bmp

diverse-bgp-path-dist

The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined today BGP has no mechanisms to distribute paths other then best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be build in parallel or they can co-exit on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The authors believe that the GROW WG would be the best place for this work.

-- draft-ietf-grow-diverse-bgp-path-dist

Geo-Location extensions in MRT

This document extends the Border Gateway Protocol (BGP) MRT export format for routing information to include terrestrial coordinates.

-- draft-ietf-grow-geomrt

MRT Format

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents.

-- draft-ietf-grow-mrt

S-VA

The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that allows any and all edge routers to shrink their FIB requirements substantially and therefore increase their useful lifetime. S-VA does not change FIB requirements for core routers. S-VA is extremely easy to configure---considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP.

-- draft-ietf-grow-simple-va

FIB Suppression

The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP.

-- draft-ietf-grow-va

HIP BONE

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.

-- draft-ietf-hip-bone

HIP CERT

The CERT parameter is a container for X.509.v3 certificates and Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter.

-- draft-ietf-hip-cert

HICCUPS

This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.

-- draft-ietf-hip-hiccups

HIP Multihoming

This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.

-- draft-ietf-hip-multihoming

Basic API Extensions for HIP

This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies.

-- draft-ietf-hip-native-api

HIP Native NAT Traversal Mode

This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures.

-- draft-ietf-hip-native-nat-traversal

HIP BONE Instance Spec for RELOAD

This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

-- draft-ietf-hip-reload-instance

Host Identity Protocol Architecture

This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel.

-- draft-ietf-hip-rfc4423-bis

Cryptographic Hash IDentifiers (ORCHID)

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus.

-- draft-ietf-hip-rfc4843-bis

Host Identity Protocol

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

-- draft-ietf-hip-rfc5201-bis

Using the ESP Transport Format with HIP

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).

-- draft-ietf-hip-rfc5202-bis

HIP Rendezvous Extension

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.

-- draft-ietf-hip-rfc5204-bis

HIP DNS Extension

This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).

-- draft-ietf-hip-rfc5205-bis

HIP Host Mobility

This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document.

-- draft-ietf-hip-rfc5206-bis

The Local Domain Name DHCPv6 Option

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side-effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients of the name of the local domain..

-- draft-ietf-hokey-ldn-discovery

ERP

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.

-- draft-ietf-hokey-rfc5296bis

draft-ietf-idr-bgp-identifier-12.txt

To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue.

-- draft-ietf-idr-bgp-identifier

BGP Issues

This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The results of these efforts are encoded in RFC4271.

-- draft-ietf-idr-bgp-issues

Updated Spec. of the IPv4 ID Field

The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime on all datagrams. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because this is obviously not the case, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field to more closely reflect current practice and to more closely match IPv6 so that the field is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used.

-- draft-ietf-intarea-ipv4-id-update

Router Alert Considerations

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.

-- draft-ietf-intarea-router-alert-considerations

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 identifies those common to all such address sharing approaches. Solution- specific discussions are out of scope.

-- draft-ietf-intarea-shared-addressing-issues

IP Flow Anonymisation Support

This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It categorizes common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an information model and Options-based method for anonymisation metadata export within the IPFIX protocol or storage in IPFIX Files.

-- draft-ietf-ipfix-anon

IPFIX Mediation Framework

This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components.

-- draft-ietf-ipfix-mediators-framework

Reporting Metrics

Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs.

-- draft-ietf-ippm-reporting-metrics

High Availability in IKEv2/IPsec

The IPsec protocol suite is widely used for the deployment of virtual private networks (VPNs). In order to make such VPNs highly available, more scalable and failure-resistant, these VPNs are implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document attempts to resolve these issues with the least possible change to the protocol. This document proposes an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues to be solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters.

-- draft-ietf-ipsecme-ipsecha-protocol

IPsec/IKE Roadmap

Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. The obsoleted IPsec roadmap [RFC2411] briefly described the interrelationship of the various classes of base IPsec documents. The major focus of [RFC2411] was to specify the recommended contents of documents specifying additional encryption and authentication algorithms.

-- draft-ietf-ipsecme-roadmap

IRIs

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.

-- draft-ietf-iri-3987bis

IS-IS BFD Enabled TLV

This document describes a TLV for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection protocol (BFD). There exist certain scenarios in which IS-IS will not react appropriately to a BFD detected forwarding plane failure without use of either this TLV or some other method.

-- draft-ietf-isis-bfd-tlv

Advertising Generic Information in IS-IS

This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) should be advertised in IS-IS LSPs and defines guidelines which should be used when flooding such information.

-- draft-ietf-isis-genapp

802.1aq Shortest Path Bridging (SPB) is being standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh network context utilizing multiple equal cost paths. This permits it to support much larger layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership (E-LINE/E-LAN/E-TREE etc). The control protocol for 802.1aq is IS-IS [IS-IS] augmented with a small number of TLVs while the encapsulating data paths are respectively 802.1ad (Provider Bridges) [PB] and 802.1ah (Provider Backbone Bridges) [PBB]. This memo documents those TLVs while providing some overview. Note that 802.1aq requires no state machine or other substantive changes to [IS-IS]. It is our intention that 802.1aq be simply a new NLPID and set of TLVs. In the event of any confusion the reader should take [IS-IS] as authoritative. Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011

-- draft-ietf-isis-ieee-aq

IPv6 Traffic Engineering in IS-IS

This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic engineered routes using IPv6 addresses.

-- draft-ietf-isis-ipv6-te

TRILL Use of IS-IS

The IETF has standardized the TRILL protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL.

-- draft-ietf-isis-trill

-- draft-ietf-l2vpn-arp-mediation

L2VPN Signaling

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3).

-- draft-ietf-l2vpn-signaling

draft-ietf-l2vpn-vpls-mcast-08.txt

This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described.

-- draft-ietf-l2vpn-vpls-mcast

draft-ietf-l3vpn-2547bis-mcast-10.txt

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document.

-- draft-ietf-l3vpn-2547bis-mcast

draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN].

-- draft-ietf-l3vpn-2547bis-mcast-bgp

draft-ietf-l3vpn-mvpn-infra-addrs-01.txt

To provide Multicast VPN service, a provider edge router originates Multicast-VPN ("MCAST-VPN") BGP routes. These routes encode addresses from the customer's address space as well as addresses from the provider's address space. The customer's address space may be either IPv4 or IPv6. Independently, the provider's address space may be either IPv4 or IPv6. The MCAST-VPN BGP routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies whether the provider addresses are IPv4 addresses or whether they are IPv6 addresses. To ensure interoperability, this document specifies that MCAST-VPN routes always encode provider IPv4 addresses as four-octet addresses, and that the distinction between an IPv4 address and an IPv6 address is signaled solely by the length of the address field.

-- draft-ietf-l3vpn-mvpn-infra-addrs

draft-ietf-l3vpn-mvpn-spmsi-joins-02.txt

The specification for Multicast Virtual Private Networks (MVPN) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as S-PMSI ("Selective Provider Multicast Service Interface") Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification so that these options can be used when the customer multicast flows are IPv6 flows.

-- draft-ietf-l3vpn-mvpn-spmsi-joins

OSPFv3 as a PE-CE routing protocol

Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document.

-- draft-ietf-l3vpn-ospfv3-pece

Locator/ID Separation Protocol (LISP)

This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop.

-- draft-ietf-lisp

LISP Alternative Topology (LISP+ALT)

This document describes a simple mapping database to be used by the Locator/ID Separation Protocol (LISP) to find Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. Termed the Alternative Logical Topology (ALT), the database is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without major changes to the existing routing infrastructure.

-- draft-ietf-lisp-alt

Interworking LISP with IPv4 and IPv6

This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces a Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.

-- draft-ietf-lisp-interworking

LISP Internet Groper (LIG)

A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works.

-- draft-ietf-lisp-lig

LISP Map-Versioning

This document describes the LISP Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism.

-- draft-ietf-lisp-map-versioning

LISP for Multicast Environments

This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture.

-- draft-ietf-lisp-multicast

DLEP

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary.

-- draft-ietf-manet-dlep

DYMO

The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile routers in wireless, multihop networks. DYMO determines unicast routes among DYMO routers within the network in an on-demand fashion, offering improved convergence in dynamic topologies.

-- draft-ietf-manet-dymo

MANET-NHDP

This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs).

-- draft-ietf-manet-nhdp

SMF

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document.

-- draft-ietf-manet-smf

Multicast Address Allocation

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.

-- draft-ietf-mboned-addrarch

Requirements for Multicast AAA

This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases where Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). In order to describe the new requirements of a multi-entity Content Deliver System(CDS) using multicast, the memo presents three basic business models: 1) the Content Provider and the Network Provider are the same entity, 2) the Content Provider(s) and the Network Provider(s) are separate entities and users are not directly billed, and 3) the Content Provider(s) and the Network Provider(s) are separate entities and users are billed based on content consumption or subscriptions. The requirements of these three models are listed and evaluated as to which aspects are already supported by existing technologies and which aspects are not. General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed and the constituent logical functional components are presented. This memo assumes that the capabilities can be realized by integrating AAA functionalities with a multicast CDS system, with IGMP/MLD at the edge of the network.

-- draft-ietf-mboned-maccnt-req

Rehoming MCAST.NET

This document proposes to migrate the MCAST.NET domain into the ARPA top level domain that is dedicated to infrastructure support. It also provides for a maintenance policy for the new MCAST.ARPA domain and covers migration issues and caveats. This document updates RFC 5771 and forms part of BCP 51. XXX reverse mapping

-- draft-ietf-mboned-mcast-arpa

Mtrace2

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.

-- draft-ietf-mboned-mtrace-v2

Multicast Ping Protocol

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information such as multicast tree setup time. This protocol is based on an implementation of tools called ssmping and asmping.

-- draft-ietf-mboned-ssmping

Traffic Selectors for Flow Bindings

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6.

-- draft-ietf-mext-binary-ts

MIPv6 Firewall Administrator guidelines

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.

-- draft-ietf-mext-firewall-admin

MIPv6 Firewall Vendor guidelines

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.

-- draft-ietf-mext-firewall-vendor

Flow binding

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses.

-- draft-ietf-mext-flow-binding

DHCPv6 Prefix Delegation for NEMO

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 NEMO. DHCPv6 prefix delegation can be used for this configuration task.

-- draft-ietf-mext-nemo-pd

Mobility Support in IPv6

This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775.

-- draft-ietf-mext-rfc3775bis

MIF Current Practices

An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges.

-- draft-ietf-mif-current-practices

Multiple Interfaces Problem Statement

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains where some configuration objects are global to the node, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses single interface nodes situation.

-- draft-ietf-mif-problem-statement

Flow Binding Support for Mobile IPv4

This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses.

-- draft-ietf-mip4-multiple-tunnel-support

HAaRO

This document describes a Home Agent assisted Route Optimization functionality to IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single Home Agent, thus the use case is Route Optimization within single organization or similar entity. The functionality adds possibility to discover eligible peer nodes based on information received from Home Agent, Network Prefixes they represent, and how to establish direct tunnel between such nodes.

-- draft-ietf-mip4-nemo-haaro

April 2008

Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario.

-- draft-ietf-mip6-bootstrapping-integrated-dhc

HA Reliability

The home agent can be a single point of failure when Mobile IPv6 and its associated supporting protocols are operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly, and provides mechanisms of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability.

-- draft-ietf-mip6-hareliability

DHCPv6 for Home Info Discovery in MIPv6

This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response.

-- draft-ietf-mip6-hiopt

Prefix Mgmt for FMIPv6 over P2P Links

Mobile IPv6 Fast Handovers specification currently does not explicitly define prefix management over point-to-point links when a mobile node uses a prefix to formulate a new care-of-address. In this document a mechanism is developed for a previous access router to request unique prefixes from a new access router, and in turn, the previous access router advertises the prefixes to the mobile node for a new care-of-address configuration. Extensions to Mobile IPv6 Fast Handovers specification are also specified in this document.

-- draft-ietf-mipshop-fmip-ptp

Transient Binding for Proxy Mobile IPv6

This document specifies a mechanism which enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry which is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.

-- draft-ietf-mipshop-transient-bce-pmipv6

ICE TCP

Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream.

-- draft-ietf-mmusic-ice-tcp

Middlebox Interactions

Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively.

-- draft-ietf-mmusic-media-path-middleboxes

Real Time Streaming Protocol 2.0 (RTSP)

This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).

-- draft-ietf-mmusic-rfc2326bis

Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service Component Link Record. & Resource Control for TE Link Bundles providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles.

-- draft-ietf-mpls-explicit-resource-control-bundle

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method.

-- draft-ietf-mpls-fastreroute-mib

draft-ietf-mpls-ip-options-05.txt

This document specifies how Label Edge Routers (LER) should behave when determining whether to MPLS encapsulate an IP packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IP packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IP option packets that belong to a prefix-based FEC yet are forwarded into an IP/MPLS network without being MPLS-encapsulated present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IP packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke.

-- draft-ietf-mpls-ip-options

draft-ietf-mpls-ldp-ipv6

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used.

-- draft-ietf-mpls-ldp-ipv6

P2MP and MP2MP LSP Setup with LDP

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.

-- draft-ietf-mpls-ldp-p2mp

draft-ietf-mpls-ldp-upstream-09.txt

This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs).

-- draft-ietf-mpls-ldp-upstream

LSP-Ping over MPLS tunnel

This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs.

-- draft-ietf-mpls-lsp-ping-enhanced-dsmap

In-band signaling with mLDP

Suppose an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages are received at the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP.

-- draft-ietf-mpls-mldp-in-band-signaling

Reqs for P2MP extensions to LDP

This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements.

-- draft-ietf-mpls-mp-ldp-reqs

draft-ietf-mpls-p2mp-lsp-ping-13.txt

Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment.

-- draft-ietf-mpls-p2mp-lsp-ping

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.

-- draft-ietf-mpls-return-path-specified-lsp-ping

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.

-- draft-ietf-mpls-tp-identifiers

MPLS-TP Loss and Delay Measurement

An essential Operations, Administration and Maintenance requirement of the MPLS Transport Profile (MPLS-TP) is the ability to monitor performance metrics for packet loss and one-way and two-way delay for MPLS-TP pseudowires, Label Switched Paths, and Sections. This document specifies protocol mechanisms to facilitate the efficient and accurate measurement of these performance metrics.

-- draft-ietf-mpls-tp-loss-delay

October 2010

The Transport Profile of Multi-Protocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

-- draft-ietf-mpls-tp-oam-framework

MPTCP API

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP.

-- draft-ietf-mptcp-api

MPTCP Architecture

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements.

-- draft-ietf-mptcp-architecture

Multipath TCP

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.

-- draft-ietf-mptcp-multiaddressed

MPTCP Threat Analysis

Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that each endpoint of a given TCP connection can use multiple IP addresses to exchange data (instead of a single IP address per endpoint as currently defined). Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. In particular, some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP.

-- draft-ietf-mptcp-threat

Multicast Listeners in PMIPv6

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document.

-- draft-ietf-multimob-pmipv6-base-solution

PMIPv6 Bulk Re-registration

Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This document also specifies a new mobility option that can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages.

-- draft-ietf-netext-bulk-re-registration

Logical Interface Support

A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is desirable on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features.

-- draft-ietf-netext-logical-interface-support

PMIPv6 Localized Routing PS

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.

-- draft-ietf-netext-pmip6-lr-ps

PMIPv6 Localized Routing

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing(LR) allows mobile nodes attached to the same or different mobile access gateways to exchange traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes an initiation mechanism for localized routing.

-- draft-ietf-netext-pmip-lr

RADIUS-PMIPv6

This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The RADIUS interactions between the Mobile Access Gateway and the RADIUS server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the Local Mobility Anchor and the RADIUS server for authorizing received Proxy Binding Update messages for the MN's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the Mobile Access Gateway and the Local Mobility Anchor generated accounting.

-- draft-ietf-netext-radius-pmip6

Runtime LMA Assignment

This document describes a runtime Local Mobility Anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6.

-- draft-ietf-netext-redirect

LMA Discovery

Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions.

-- draft-ietf-netlmm-lma-discovery

PMIPv6-MIPv6 Interactions

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described.

-- draft-ietf-netlmm-mip-interactions

pmip6MIB

This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity.

-- draft-ietf-netlmm-pmipv6-mib

Mapping YANG to DSDL

This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed.

-- draft-ietf-netmod-dsdl-map

Admin 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 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.

-- draft-ietf-nfsv4-federated-fs-admin

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.

-- draft-ietf-nfsv4-federated-fs-protocol

draft-ietf-nfsv4v6-ipv6

This Internet-Draft provides the description of problem set faced by NFS and its various side band protocols when implemented over IPv4 and IPv6 networks in various deployment scenarios. Solution to the various problems are also given in the draft and are sought for approval in the respective NFS and side band protocol versions.

-- draft-ietf-nfsv4-ipv4v6

draft-ietf-nfsv4-ipv6

This Internet-Draft provides the description of problems faced by NFS and its various side band protocols, when implemented over IPv6 in various deployment scenarios. Solutions to the various problems are also given in the draft and are sought for approval.

-- draft-ietf-nfsv4-ipv6

NFSv4

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, replaces RFC 3530 as the definition of the NFS version 4 protocol.

-- draft-ietf-nfsv4-rfc3530bis

NSIS Signaling in Mobility

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operation can work in different scenarios, with mobility management protocols.

-- draft-ietf-nsis-applicability-mobility-signaling

NSLP AUTH

Signaling layer protocols specified within the NSIS framework may rely on the GIST (General Internet Signaling Transport) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.

-- draft-ietf-nsis-nslp-auth

NSIS Operation over IP Tunnels

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation which masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.

-- draft-ietf-nsis-tunnel

Overview of OAM Mechanisms

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for detecting and reporting connection failures or measurement of connection performance parameters. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF, as well as a comparison to other OAM mechanisms that have been defined by the IEEE and ITU-T.

-- draft-ietf-opsawg-oam-overview

Security Efforts and Documents

This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO).

-- draft-ietf-opsec-efforts

Crypto Reqsfor Routing Protocols

The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS) and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS and OSPF. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. Similarly RIPng and OSPFv3 support IPSec algorithms for authenticating their protocol packets. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time.

-- draft-ietf-opsec-igp-crypto-requirements

IPv4 Security Assessment

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).

-- draft-ietf-opsec-ip-security

Protect Router Control Plane

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane or rate limited to an acceptable level.

-- draft-ietf-opsec-protect-control-plane

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-ietf-ospf-multi-instance

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-ietf-ospf-transport-instance

RELOAD Base

This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.

-- draft-ietf-p2psip-base

P2PSIP Overlay Diagnostics

This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks.

-- draft-ietf-p2psip-diagnostics

PCEP Ext for GMPLS

This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane.

-- draft-ietf-pce-gmpls-pcep-extensions

This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.

-- draft-ietf-pce-pcep-mib

3-in-1 PCN Encoding

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding builds on the baseline encoding of RFC5696 and provides for three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding.

-- draft-ietf-pcn-3-in-1-encoding

PCN CL Boundary Node Behaviour

Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour.

-- draft-ietf-pcn-cl-edge-behaviour

Document

Pre-congestion notification (PCN) is a link-specific and load- dependent packet marking mechanism for Differentiated Services networks. The packet markings are evaluated by egress nodes of PCN domains and the result is used for admission control and flow termination decisions. Two different types of markings have been defined. This document gives a summary of the marking requirements, the constraints to encode them in the current IP header (version 4 and above), and it explains why the PCN WG currently supports different encoding schemes for PCN marking.

-- draft-ietf-pcn-encoding-comparison

PCN Signaling requirements

Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: PCN feedback is carried from the PCN-egress-node to the decision point and the decision point may demand for the measurement and delivery of the PCN rate sent at the PCN-ingress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node.

-- draft-ietf-pcn-signaling-requirements

PCN SM Boundary Node Behaviour

Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN edge behaviour.

-- draft-ietf-pcn-sm-edge-behaviour

Port Control Protocol (PCP)

Port Control Protocol is an address-family independent mechanism to control how incoming packets are forwarded by upstream devices such as network address translators (NATs) and simple IPv6 firewalls.

-- draft-ietf-pcp-base

PIM Group-to-RP Mapping

Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain which supports Any Source Multicast (ASM) maintains Group-to-RP mappings which are used to identify a Rendezvous Point(RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document defines a standard algorithm to deterministically choose between several group-to-rp mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm.

-- draft-ietf-pim-group-rp-mapping

A Reliable Transport Mechanism for PIM

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.

-- draft-ietf-pim-port

draft-ietf-pwe3-dynamic-ms-pw-13.txt

There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers.

-- draft-ietf-pwe3-dynamic-ms-pw

RADIUS Design Guidelines

This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs).

-- draft-ietf-radext-design

RADIUS IPv6 Access

This document specifies IPv6 RADIUS attributes, which complement those of RFC3162, and are intended to be used in residential broadband networks, where specific user configuration information is expected to be passed as part of the AAA process between a NAS and an AAA server. The attributes cover the assignment or reporting of the following; a specific host IPv6 address; a recursive DNS IPv6 server address; a specific IPv6 route announced to a host; a named IPv6 delegated prefix pool to be used for assignments to an accessing host.

-- draft-ietf-radext-ipv6-access

RADIUS Over TCP

The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. 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 April 12, 2011 Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

-- draft-ietf-radext-tcp-transport

FCAST: Scalable Object Delivery

This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service.

-- draft-ietf-rmt-fcast

FLUTE

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926.

-- draft-ietf-rmt-flute-revised

draft-ietf-roll-minrank-hysteresis-of

Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG).

-- draft-ietf-roll-minrank-hysteresis-of

draft-ietf-roll-of0

The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages to maximize connectivity.

-- draft-ietf-roll-of0

draft-ietf-roll-p2p-rpl-01

Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria.

-- draft-ietf-roll-p2p-rpl

draft-ietf-roll-routing-metrics-12

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 to be used by the Routing for Low Power and lossy networks (RPL) routing protocol.

-- draft-ietf-roll-routing-metrics

draft-ietf-roll-rpl-15

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 processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (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.

-- draft-ietf-roll-rpl

Security Framework for ROLL

This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL).

-- draft-ietf-roll-security-framework

draft-ietf-roll-trickle-05

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use.

-- draft-ietf-roll-trickle

Composite Link Requirements

There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix.

-- draft-ietf-rtgwg-cl-requirement

savi-dhcp

This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address.

-- draft-ietf-savi-dhcp

FCFS SAVI

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.

-- draft-ietf-savi-fcfs

SEND SAVI

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-ietf-savi-send

SAVI Threat Scope

This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats.

-- draft-ietf-savi-threat-scope

Shim6 Applicability Statement

This document discusses the applicability of the Shim6 IPv6 protocol and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.

-- draft-ietf-shim6-applicability

Multihoming Shim API

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.

-- draft-ietf-shim6-multihome-shim-api

RPKI Architecture

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 (AS) 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.

-- draft-ietf-sidr-arch

Certificate Policy for the RPKI

This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet resource holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.

-- draft-ietf-sidr-cp

RPKI Local TA Management

This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document.

-- draft-ietf-sidr-ltamgmt

Resource Certificate Profile

This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of Resources (INRs). The certificates issued under this profile are used to convey the Issuer's authorisation of the Subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). The document also specifies profiles for the format of certificate requests. The document also specifies the Relying Party RPKI certificate path validation procedure.

-- draft-ietf-sidr-res-certs

Rescert Provisioning

This document defines a framework for certificate management interactions between a resource issuer ("Issuer") and a resource recipient ("Subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the Subject, and corresponding responses from the Issuer encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework.

-- draft-ietf-sidr-rescerts-provisioning

Route Origin Authorizations

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.

-- draft-ietf-sidr-roa-format

Route Validation

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.

-- draft-ietf-sidr-roa-validation

The RPKI/Router Protocol

In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh.

-- draft-ietf-sidr-rpki-rtr

Securing RPSL

This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects.

-- draft-ietf-sidr-rpsl-sig

SIP CLF

Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by proxies, registrars, redirect servers as well as back-to-back user agents.

-- draft-ietf-sipclf-problem-statement

SIP Configuration Framework

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) User Agents in SIP deployments. The framework provides a means to deliver profile data that User Agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP User Agents can discover sources, request profiles and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope.

-- draft-ietf-sipping-config-framework

Media Policy Dataset

This specification defines a document format for the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in a session. This document format is based on XML and can be used to describe the properties of a specific SIP session or to define policies that are then applied to SIP sessions.

-- draft-ietf-sipping-media-policy-dataset

NAT Scenarios

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding flows.

-- draft-ietf-sipping-nat-scenarios

IPv6 Transition in SIP

This document describes how IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered.

-- draft-ietf-sipping-v6-transition

November 2010

6rd is One of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The DHCP 6rd option has been defined to configure 6rd CPE. But in many networks, the configuration information may be stored in AAA servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a RADIUS attribute that carries 6rd configuration information from AAA server to BNG.

-- draft-ietf-softwire-6rd-radius-attrib

DS-Lite RADIUS Extensions

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix. DS-Lite requires to pre-configure the AFTR tunnel information on the B4 element. In many networks, the customer profile information may be stored in AAA servers while client configurations are mainly provided through DHC protocol. This document specifies two new RADIUS attributes to carry Dual-Stack Lite Address Family Transition Router (AFTR) IPv6 address and name; the RADIUS attributes are defined based on the equivalent DHCPv6 options already specified in draft-ietf-softwire-ds-lite-tunnel-option. These RADIUS attributes are meant to be used between the RADIUS Server and the NAS, they are not intended to be used directly between the B4 element and the RADIUS Server.

-- draft-ietf-softwire-dslite-radius-ext

DS-Lite DHCPv6 Option

This document specifies a DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address.

-- draft-ietf-softwire-ds-lite-tunnel-option

Dual-stack lite

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 in service provider networks. 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 Network Address Translation (NAT).

-- draft-ietf-softwire-dual-stack-lite

Gateway-Initiated DS-Lite

Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire.

-- draft-ietf-softwire-gateway-init-ds-lite

MRCPv2

The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.

-- draft-ietf-speechsc-mrcpv2

SIP Session Peering Requirements

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions.

-- draft-ietf-speermint-requirements

VoIP SIP Peering Use Cases

This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today.

-- draft-ietf-speermint-voip-consolidated-usecases

iFCP MIB

This document defines Management Information Base (MIB) objects to monitor and control iFCP Gateway instances and their associated sessions, for use with network management protocols. This document obsoletes RFC4369.

-- draft-ietf-storm-ifcpmib

iSCSI (Consolidated)

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document consolidates RFCs 3720, 3980, 4850 and 5048 into a single document and makes additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in RFCs 3720, 3721, 3980, 4850 and 5048 whenever there is such a question.

-- draft-ietf-storm-iscsi-cons

Making TCP more Robust to LCDs

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in case of connectivity disruptions.

-- draft-ietf-tcpm-tcp-lcd

This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2.

-- draft-ietf-tls-rfc4347-bis

TLS Extension Definitions

This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.

-- draft-ietf-tls-rfc4366-bis

RBridges: TRILL Base MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing RBridges, which are devices that implement the TRILL protocol.

-- draft-ietf-trill-rbridge-mib

TRILL Header Options

The TRILL base protocol specification [RFCtrill], specifies minimal hooks for TRILL Header options. This draft specifies the format for options and an initial set of options.

-- draft-ietf-trill-rbridge-options

RBridge Protocol

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.

-- draft-ietf-trill-rbridge-protocol

RBridges: VLAN and Priority Regions

Within an RBridge campus, the VLAN and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data VLAN and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional RBridge feature to provide this function.

-- draft-ietf-trill-rbridge-vlan-mapping

Byte and Packet Congestion Notification

This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used.

-- draft-ietf-tsvwg-byte-pkt-congest

RSVP Extensions for Admission Priority

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Based on current security concerns, these extensions are intended for use in a single administrative domain.

-- draft-ietf-tsvwg-emergency-rsvp

Service Name and Port Number Procedures

This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number 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 IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA Service Name and Port assignment procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered.

-- draft-ietf-tsvwg-iana-ports

RSVP Keying Applicability

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The document also discusses applicability of encrypting RSVP messages.

-- draft-ietf-tsvwg-rsvp-security-groupkeying

SCTP sockets API

This document describes a mapping of the Stream Control Transmission Protocol SCTP into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme.

-- draft-ietf-tsvwg-sctpsocket

March 10, 2008

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one- size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document updates and replaces RFC 3177.

-- draft-ietf-v6ops-3177bis-end-sites

Simple Security in IPv6 Gateway CPE

This document identifies a set of recommendations for the makers of devices describing how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.

-- draft-ietf-v6ops-cpe-simple-security

October 2010

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, the IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual stack environments are not able to meet the transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier- Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational change required during the IPv4 to IPv6 migration or coexistence period. This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6-enabled hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy IPv4 ISP network unchanged. It is suitable for the initial stage of IPv4 to IPv6 migration. Unlike NAT444 based CGN alone, Incremental CGN also supports and encourages transition towards dual- stack or IPv6-only ISP networks. A smooth transition to IPv6 deployment is also described in this document. An integrated configurable CGN device and an adaptive Home Gateway (HG) device are introduced. Both HG and CGN are re-usable devices during different transition periods. It avoids potential multiple upgrades. It enables IPv6 migration to be incrementally achieved according to the real user requirements.

-- draft-ietf-v6ops-incremental-cgn

IPv6 CE router requirements

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.

-- draft-ietf-v6ops-ipv6-cpe-router

IPv6 Multihoming without NAT

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria .

-- draft-ietf-v6ops-multihoming-without-nat66

IPv6 RA-Guard

Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status.

-- draft-ietf-v6ops-ra-guard

Rogue IPv6 Router Advertisements

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this draft we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.

-- draft-ietf-v6ops-rogue-ra

Routing Loop Attack

This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures.

-- draft-ietf-v6ops-tunnel-loops

Tunneling Security Concerns

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed today.

-- draft-ietf-v6ops-tunnel-security-concerns

Transition Scenarios Framework

This document sets out a framework for the presentation of scenarios and recommendations for a variety of approaches to the transition from IPv4 to IPv6, given the necessity for a long period of co- existence of the two protocols.

-- draft-ietf-v6ops-v4v6tran-framework

IPv6 AAAA DNS Whitelisting Implications

The objective of this document is to describe what whitelisting of DNS AAAA resource records is, or DNS whitelisting for short, as well as what the implications of this emerging practice are and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers.

-- draft-ietf-v6ops-v6-aaaa-whitelisting-implications

IPv6 in Mobile Networks

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.

-- draft-ietf-v6ops-v6-in-mobile-networks

VRRP unified MIB

This specification defines a Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787.

-- draft-ietf-vrrp-unified-mib

XMPP Core

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.

-- draft-ietf-xmpp-3920bis

XMPP Address Format

This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non- ASCII characters.

-- draft-ietf-xmpp-address

YAM 5321bis Evaluation

This memo is a preliminary evaluation of RFC 5321, Simple Mail Transfer Protocol for advancement from Draft to Full Standard. It has been prepared by the The Yet Another Mail Working Group. THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS WRITTEN TO FACILITATE DISCUSSION WITH THE IESG.

-- draft-ietf-yam-5321bis-smtp-pre-evaluation

DNSBL BCP

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists ("DNSBLs") of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. The document may seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list.

-- draft-irtf-asrg-bcp-blacklists

Reliability-only Checksum Ciphersuites

The Delay-Tolerant Networking Bundle Protocol includes a custody transfer mechanism to provide acknowledgements of receipt for particular bundles. No checksum is included in the basic DTN Bundle Protocol, however, so at intermediate hops, it is not possible to verify that bundles have been either forwarded or passed through convergence layers without error. Without assurance that a bundle has been received without errors, the custody transfer receipt cannot guarantee that a correct copy of the bundle has been transferred, and errored bundles are forwarded when the destination cannot use the errored content, and discarding the errored bundle early would have been better for performance and throughput reasons. This document addresses that situation by defining new ciphersuites for use within the existing Bundle Security Protocol's Payload Integrity Block (formerly called the Payload Security Block [ED: remove old name before RFC]) to provide error-detection functions that do not require support for other, more complex, security-providing ciphersuites that protect integrity against deliberate modifications. This creates the checksum service needed for error-free reliability, and does so by separating security concerns from the few new reliability-only ciphersuite definitions that are introduced here. The reliability- only ciphersuites given here are intended to protect only against errors and accidental modification; not against deliberate integrity violations. This document discusses the advantages and disadvantages of this approach and the existing constraints that combined to drive this design.

-- draft-irtf-dtnrg-bundle-checksum

Using SDNVs

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bit-string with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy, and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

-- draft-irtf-dtnrg-sdnv

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.

-- draft-irtf-hip-experiment

HIP DHT Interface

This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service.

-- draft-irtf-hiprg-dht

Investigation in HIP Proxies

HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. A core objective of a HIP proxy is to facilitate the communications between legacy (or Non- HIP) hosts and HIP hosts while not modifying their protocol stacks. In this document, the legacy hosts served by proxies are referred to as the Made-up Legacy (ML) hosts. Currently, various designing solutions of HIP proxies have been proposed. These solutions may be applicable in different working circumstances. In this document, we attempt to investigate these solutions in detail and compare their performances in different scenarios.

-- draft-irtf-hiprg-proxies

MPA Framework

This document describes 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 its applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented MPA mechanism for various network layer and application layer mobility protocols and report summary of experimental performance results in this document. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.

-- draft-irtf-mobopts-mpa-framework

Design Goals

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi- homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture.

-- draft-irtf-rrg-design-goals

RRG Recommendation

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions which could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group.

-- draft-irtf-rrg-recommendation

Flow-based mobility support

IN Proxy Mobile IPv6 (PMIPv6), a multi-homed MN can connect to the PMIPv6 by using only one interface even though it has multiple interfaces. It would be efficient when such a multi-homed MN can connect to the PMIPv6 by using all of its interfaces. If such a multi-homed MN can utilize all of its interfaces, flow mobility can be provided that the MN handovers one or more flows from one interface to another without re-establishing sessions. This document specifies the layer-3 based flow mobility mechanism by considering the intention of the MN. Here, a MN chooses the interface for sending the service traffic and transmits the traffic by using the chosen interface. The PMIPv6 domain can know the intention of the MN when a MAG receives a service flow via a specific network.

-- draft-jaehwoon-netext-flowmob

LISP Deployment

This document discusses the different scenarios in which the LISP protocol may be deployed. Changes or extensions to other protocols needed by some of the scenarios are also highlighted.

-- draft-jakab-lisp-deployment

OSPF Integrity Checks

This document describes an extension to OSPFv2 and OSPFv3 to allow a stronger integrity check to be applied to the protocol packets, than the default OSPF checksum, which is known to be weak. The extension allows OSPF speakers to negotiate the use of a CRC integrity check, as a new psuedo-authentication type.

-- draft-jakma-ospf-integrity

October 2010

The Internet is in the early stages of what may be a protracted period of coexistence of IPv4 and IPv6. Network operators are challenged with the task of activating IPv6 without negative impact on operating IPv4 networks and their customers. This draft is an informational "annotated bibliography" compiled to help in the analysis and development of basic guidelines and recommendations for network operators. The goal of this document is to survey the current state of RFCs, Internet-Drafts and external reference materials that define the use cases, problem statements, protocols, transition mechanisms and coexistence tools that will be of interest to a network operator planning to turn on IPv6.

-- draft-jankiewicz-v6ops-v4v6biblio

Sensor Markup

This specification defines media types for representing simple sensor measurements in JSON. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP to transport the values of a sensor.

-- draft-jennings-senml

TFT Reference

This memo describes a reference to third generation partner ship project (3GPP) defined traffic flow template (TFT) as a traffic selector in the flow based routing mechanism described in the flow binding draft [1]. This memo, further specifies a new traffic selector sub-option format to be used with the flow binding mobility option defined in draft [1], in order to transport the TFT reference from the mobile node to its home agent in a 3GPP SAE (service architecture evolution) scenario.

-- draft-jeyatharan-mext-flow-tftemp-reference

August 2010

In the IPv6 address allocation scenarios, node self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document discusses the requirements of address registration and analyzes the possible solutions.

-- draft-jiang-6man-addr-registration-req

July 2010

During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Multicast services across IPv6 and IPv4 networks are also needed. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It is mainly based on content cache concept. Without packet-based translation, it retires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates. It also acts as a multicast source in IPvY network where the multicast client locates.

-- draft-jiang-behave-v4v6mc-proxy

November 2010

A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described.

-- draft-jiang-dhc-cga-config-dhcpv6

Encoding of ROADM

Reconfigurable add/drop optical multiplexers(ROADM) featured highly asymmetric switching capability, is an essential element in current wavelength switched optical network(WSON).Because the multiple degree Reconfigurable add/drop optical multiplexer(ROADM) can not only add/ drop wavelength but also switch wavelength, it is necessary to know the switch connectivity offered by such a network element. With the development of ROADM, the constraint of wavelength and direction is abated, so the encoding of the ROADM needs improvement. This memo provides a novel encoding for different ROADMs, Which is applicable to the encoding of different kind of ROADMs.

-- draft-ji-ccamp-wson-encoding

June 29, 2010

This document defines a central policy controlling network-based mobility management solution through Authentication, Authorization, Accounting (AAA), and policy controller interactions between Proxy Mobile IPv6 entities(both Mobile Access Gateway and Local Mobility Anchor) under an AAA server and policy server group within a Proxy Mobile IPv6 Domain. The AAA and policy interactions are not only used to download and update mobile node specific user data information between Proxy Mobile IPv6 entities and a remote policy store, but also update the local mobility anchor about the current location of the mobile node instead of signaling messages between the mobile access gateway and local mobility anchor.

-- draft-jie-netext-cpc-pmip6

PBB-PMIPv6

This document proposes an enhanced handover scheme of the Proxy Mobile IPv6 (PMIPv6) with partial bicasting in wireless networks. In the proposed PMIPv6 handover scheme, when a mobile node (MN) moves into a new network and thus its Mobile Access Gateway (MAG) performs the binding update to the Local Mobility Anchor (LMA), the LMA begins the 'partial' bicasting of data packets will be buffered at the new MAG as well as the previous MAG. Then, the data packets will be buffered at the new MAG during handover and then forwarded to MN after the handover operations are completed. The proposed scheme can reduce handover delays and packet losses, and can also use the network resource of wireless links more effectively.

-- draft-jikim-netext-pbbpmipv6

draft-jin-mpls-mldp-leaf-discovery

This document describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function can then be used for multiplexing/aggregating various applications relying on mLDP as the P2MP/MP2MP LSP setup. Examples of such applications are P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast].

-- draft-jin-mpls-mldp-leaf-discovery

DHCPv6 Redundancy Considerations

This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document.

-- draft-jjmb-dhc-dhcpv6-redundancy-consider

IKEv2SecurityLabel

This document describes extensions to the Internet Key Exchange Protocol Version 2 [RFC4306] to support Mandatory Access Control (MAC) security labels used on deployed systems.

-- draft-jml-ipsec-ikev2-security-label

Extended RAMS

This document proposes Extended RAMS (ERAMS), which is a complement to the unicast based Rapid Acquisition for Multicast based Streaming (RAMS) discussed in [ID-RAMS]. The outline of this added functionality to RAMS is to gather up Rapid Acquisition requests for many users and transmit them in dedicated multicast streams. With this technique the peak load on the retransmission server and on the outgoing link from the retransmission server can be reduced. For a problem description of the channel change problem in multicast based IPTV the reader is encouraged to read [ID-RAMS].

-- draft-johansson-avt-mcast-based-rams

Using the ESP Transport Format with HIP

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).

-- draft-jokela-hip-rfc5202-bis

4-octet AS number application scenario

This document is designed to help organizations in their use of 4- octet AS numbers in the future by checking the possibility of interaction between 2-octet AS numbers and 4-octet AS numbers for each scenario, based on the compatibility of heterogeneous equipment used in the actual network related to 4-octet AS numbers, and by verifying the interoperability of networks specified in each scenario - before using 4-octet AS numbers, before applying 4-octet AS numbers, as well as the influence on service traffic at the time of interaction.

-- draft-joo-idr-fouras-application-scenario

qpmipv6

This Document proposes two extension schemes of PMIPv6, called Query-based PMIPv6 (QPMIPv6) and Signaling Query-based PMIPv6 (S- QPMIPv6), which send the binding query messages to LMA to get the care-of-address of a mobile node and to deliver the subsequent data packet over optimized data path. The proposed two schemes have some differences with each other. We will show that the performances of the schemes comparing PMIPv6 with QPMIPv6 and S-QPMIPv6.

-- draft-jwpark-netext-qpmipv6

Global-connectivity

This document specifies the translation mechanism mapping IPv6 address with 128 bits to the Adaptation Identifier (AID) with shorter length. When a device in IEEE802.15.4 domain needs to communicate with other nodes in IPv6 domain, it should acquire source AID and destination AID corresponding to source IPv6 address and destination IPv6 address, respectively from an IPv6 translation-capable gateway. The device will send packets using those AIDs to the gateway, and then the gateway will translate them to normal IPv6 addresses.

-- draft-kahng-6lowpan-global-connectivity

Problems with SIP GRUUs

This document identifies some issues discovered in deployments of the SIP GRUU mechanism defined in [RFC5627], cases in which GRUUs may be harmful, and considerations for B2BUAs handling GRUUs.

-- draft-kaplan-dispatch-gruu-problematic

IPv6 ISP Listings

There are many web sites that give listings of IPv6 enabled service providers, or rate ISPs according to their IPv6 enabledness. This document intends to gather information about currently known sites and their methods of checking an ISPs enabledness. This document also summarizes a basic guideline that these listings may consider when checking an ISPs IPv6 enabledness.

-- draft-kawamura-ipv6-isp-listings

MTOCP

To cope with the lack of IP multicast support in today's Internet, a multiparty transport overlay architecture is presented in this document. The goal behind placing the overlay paradigm at the transport layer is to support both multicast-capable and non- multicast IP networks while providing an application-agnostic delivery service for group communications. In particular, this document specifies the Multiparty Transport Overlay Control Protocol (MTOCP) used to create, update and remove multiparty transport trees in an IP network.

-- draft-kellil-sam-mtocp

AFI Specific Route Target Distribution

The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. Furthermore, the current specification mandates that Route Targets exchanged using the current specification are applied towards filtering for all VPN applications that uses the notion of Route Target BGP extended communities. In particular, the same Route Target distribution mechanism is used to exchange VPNv4, VPNv6 and L2VPN prefixes. The IPv6 specific Route Target extended community is defined in RFC5701 as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension to the current constrained route distribution specification that allows BGP speakers to distribute Route Target prefixes using multiple different Address Families thereby limiting the application of Route Target prefix filters to the specific address family under which it is advertised. Furtheremore, this document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes.

-- draft-keyur-bgp-af-specific-rt-constrain

ALTO Server Discovery Protocol

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. Entities seeking guidance need to discover and possibly select an ALTO server to ask. This is called ALTO server discovery. This memo describes an ALTO server discovery mechanism based on several alternative mechanisms that are applicable in a diverse set of ALTO deployments.

-- draft-kiesel-alto-3pdisc

A fast LSP-alert Mechanism

There are applications (e.g. fault-management, OAM) that need to alert LSRs along an LSP. Currently defined alert mechanisms for labeled packets (e.g., TTL expiry, GAL, etc) alert a single LSR along the LSP with one alert message. To alert multiple LSRs along the LSP, multiple alert messages have to be generated. This results in increasing delays in generating the message as the number of LSRs increase. If the message is used to recover from faults, it results in increasing traffic loss. This document defines a simple and fast mechanism that can alert all the LSRs along a LSP.

-- draft-kini-mpls-fast-lsp-alert

Efficient Facility Backup FRR

Fast Re-route (FRR) using facility backup is a widely deployed MPLS protection mechanism that can protect against link and node failure. It provides a fast protection switch mechanism to minimize traffic loss (typically sub 50msec) if the node that detects the failure locally, does the repair by re-routing the protected traffic to go over the backup tunnel. A direct application of this mechanism to a ring topology results in an inefficient use of link bandwidth that could also result in degraded service. This document describes a mechanism to do it without such problems.

-- draft-kini-mpls-ring-frr-facility-backup

Packet PWE3 - Efficient for IP/MPLS

A Packet Pseudowire (PPW) must be able to carry a packet of any protocol that can be carried over Ethernet. In many cases IP and MPLS are the pre-dominant protocols on a PPW transported over an MPLS PSN. Other protocols are used mainly for control purposes. In such a scenario it is highly beneficial to make IP/MPLS encapsulation efficient. This document defines such an encapsulation while retaining the ability to exchange packets of any other protocol over the PPW.

-- draft-kini-pwe3-pkt-encap-efficient-ip-mpls

private-ip-sp-cores

The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.

-- draft-kirkham-private-ip-sp-cores

Simplified DNS Query

This document discusses a simplified regular DNS query (resolving from a domain name to IP address(es)) method under IPv4/IPv6 mixed environment. Under IPv4/IPv6 mixed environment, in order to obtain IPv4 and IPv6 addresses of the node with its one domain name argument by the DNS query(ies), it requires for a client to issue two times of DNS queries transaction (one for A(IPv4) record query, the other for AAAA(IPv6) record query). In shortly to say the current DNS query method: "Two DNS queries transaction is required for One domain name resolving." Two DNS queries transaction method is complicated, inefficient and problematic. It is clear that this two DNS queries method is not suitable and not optimized for current IPv4/IPv6 mixed environment, and this method will never last to the future IPv6 fully deployed environment. Goals of this document are: 1. to clarify the problems of current regular DNS query method 2. to propose a simplified regular DNS query method ("One DNS query transaction for One domain name resolving")

-- draft-kitamura-ipv6-simple-dns-query

LISP-MN NAT Traversal

The Locator/Identifier Separation Protocol (LISP) is a new naming and addressing architecture to solve the Internet's routing scaling problem. It separates global routing in the Internet from local routing and naming in end-user networks. The basic LISP architecture does not support mobility. The mobility extension LISP Mobile Node (LISP-MN) describes a mechanism that extends LISP to support mobile nodes and enables them to roam into LISP and non-LISP networks while being reachable under the same address. Currently, LISP-MN does not support networks that use network address translation (NAT). This document presents an extension for LISP-MN that makes LISP mobile nodes behind a NAT globally reachable.

-- draft-klein-lisp-mn-nat-traversal

ISD Definition

The current IETF standard-track maturity level definitions, including the assumption that most specification of successful protocols would advance rapidly to Internet Standard, the never-used automatic expiration mechanism, and the STD nnnn designation, have not worked well. Users of IETF Standards have found it difficult to determine what standards were associated with others in groups, the actual status of specifications within a related group, and the level of interoperability testing and deployment and use for any given standard or set of features. The community has rarely used the "requirement level" mechanism in recent years. There is now an errata mechanism for published RFCs, but the errata lists do not provide authoritative, consensus-based, corrections to standards- track documents. This document suggests that all of those issues are symptoms of a single system of interrelated issues and problems and proposes an integrated solution.

-- draft-klensin-isdbis

DisCo

This document defines a RELOAD Usage for Distributed Conference Control (DisCo) with SIP. DisCo splits the semantic of identifier and locator of a SIP conference URI using a new Kind data structure. Conference members are enabled to select conference controllers based on proximity awareness. DisCo proposes call delegation to balance load at focus peers. The document addresses also aspects of security and trust, as well as compatibility for conference unaware clients.

-- draft-knauf-p2psip-disco

DNS Glue Clarification

This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different top level domains.

-- draft-koch-dns-glue-clarifications

IPv6 prefixlen p2p

On inter-router point-to-point links, it is useful for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This document specifies motivation and usages of 127-bit IPv6 prefix lengths on inter-router point-to-point links.

-- draft-kohno-ipv6-prefixlen-p2p

ALM Extensions to RELOAD

We describe protocol and API extensions to P2P-SIP for constructing Scalable Adaptive Multicast (SAM) sessions using hybrid combinations of Application Layer Multicast (ALM), native multicast, and multicast tunnels. We use the AMT relay and gateway elements for interoperation between native regions and ALM regions. The baseline architecture allows different overlay algorithms and different ALM control algorithms to be used.

-- draft-kolberg-sam-baseline-protocol

MPLS Entropy Labels

Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the notion of "entropy labels". It defines the concept, describes why they are needed, suggests how they can be used, and enumerates properties of entropy labels that allow optimal benefit.

-- draft-kompella-mpls-entropy-label

Multi-path RSVP-TE LSPs

This document describes extensions to Resource ReSerVation Protocol - Traffic Engineering for the set up of multi-path Traffic Engineered Label Switched Paths (LSPs) in Multi Protocol Label Switching and Generalized MPLS networks, i.e., LSPs that conform to traffic engineering constraints, but follow multiple independent paths from the source to the destination that allow load balancing.

-- draft-kompella-mpls-rsvp-ecmp

Multi-access Indicator for Flow Mobility

When a Mobile Node attaches to the mobile network using multiple access networks, it is important for the Mobile Network Gateway to know whether the Mobile Node is capable of simultaneous multi-access, so that the former can distribute the traffic flows using the most appropriate interface. This document defines a new EAP attribute which can be used for such an indication to the Mobile Network Gateway.

-- draft-koodli-netext-multiaccess-indicator

Learning NAT64 prefix

Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses number of proposed solutions for communicating if the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. This enables both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis.

-- draft-korhonen-behave-nat64-learn-analysis

EDNS0 synthesis flags

Advanced hosts and applications benefit of the knowledge of an IPv6 address, AAAA record, synthesis taking place in the network. This draft proposes new ENDS0 option for communicating the synthesis is taking place, used address format, and the IPv6 prefix and suffix used by the DNS64. The communicated information enables hosts to perform local IPv6 address synthesis.

-- draft-korhonen-edns0-synthesis-flag

TLS-based MIPv6 Security Framework

Mobile IPv6 signaling between the mobile node and home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol part of the IP stack and the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based security architectures makes implementation and deployment of the protocol infeasible for numerous reasons. This document proposes an alternate security framework, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent.

-- draft-korhonen-mext-mip6-altsec

IPv6 in 3GPP EPS

The increased use of data services, growth of subscribers in 3GPP based mobile networks, and the impending exhaustion of available IPv4 addresses from the registries is driving the need to specify the transition to IPv6 solutions in 3GPP network architectures. This document describes the support for IPv6 in 3GPP network architectures and a solution to transition to IPv6 using a dual-stack approach.

-- draft-korhonen-v6ops-3gpp-eps

IPv6 Reserved Bits

The IPv6 header does not contain any reserved bits for future expansion. This document sets aside 4 bits from the flow label field for future expansion.

-- draft-krishnan-6man-header-reserved-bits

SLAAC Clarifications

The IPv6 stateless auto-configuration(SLAAC) mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. This document describes a failure scenario for SLAAC and discusses how hosts can recover from this failure in a properly configured network.

-- draft-krishnan-6man-rs-lost

Line Identification in RS

In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to the N:1 VLAN allocation model.

-- draft-krishnan-6man-rs-mark

The case against Hop-by-Hop options

The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks.

-- draft-krishnan-ipv6-hopbyhop

PMIPv6 Localized Routing

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing allows mobile nodes attached to the same or different mobile access gateways to exchange traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes an initiation mechanism for localized routing.

-- draft-krishnan-netext-pmip-lr

draft-kaursingh-lsn-deployment-00.txt

This document specifies NAT44 [RFC3022] with Large Scale NAT [draft- nishitani-cgn-04] integration options along with production model experience. The NAT44/LSN implementation is associated with the NAT444 [draft-shirasaki-nat444-01] model. Service Providers are preparing for IPv4 address depletion by enabling IPv6 and/or extending connectivity for IPv4 to support legacy Internet end points. This document provides practical integration options for Large Scale NAT systems which enable provider NAT44 and is applicable primarily to service providers. The document does not intend to argue the merits of NAT444 versus other IPv4 run out technology options

-- draft-kuarsingh-lsn-deployment

6to4 Provider Managed Tunnels

This document provides an overview of a framework describing the management of 6to4 [RFC3056] tunnels within a provider network. The 6to4 provider managed tunnel, or 6to4-PMT, combines the current behavior of 6to4 [RFC3056] utilizing the IPv4 anycast based connectivity defined in [RFC3068] along with IPv6 Prefix Translation. The framework is intended to allow Service Providers an option to translate 6to4 based addresses to provider based addresses utilizing provider assigned prefixes. The framework offers IPv6 connectivity to 6to4 compatible endpoints [RFC3056] with the advantage of a stable provider assigned prefix. The 6to4-PMT operation is not intended to replace Native IPv6 connectivity nor 6RD, but rather provide a connectivity before such options can be deployed by an operator.

-- draft-kuarsingh-v6ops-6to4-provider-managed-tunnel

July 2010

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). New RSVP-TE extensions are required to support multiple MPLS-TE based BGP/MPLS IP-VPNs that are interconnected via the same Provider Edge (PE) routers. These extensions are necessary so that RSVP control messages from the Customer Edge (CE) equipment, such as Path messages and Resv messages, are appropriately handled by the PE routers. This document defines the procedure and objects that enable a PE router to distinguish between BGP/MPLS IP-VPNs.

-- draft-kumaki-murai-ccamp-rsvp-te-l3vpn

October 2010

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). New RSVP-TE extensions are required to support multiple MPLS-TE based BGP/MPLS IP-VPNs that are interconnected via the same Provider Edge (PE) routers. These extensions are necessary so that RSVP control messages from the Customer Edge (CE) equipment, such as Path messages and Resv messages, are appropriately handled by the PE routers. This document defines the procedure and objects that enable a PE router to distinguish between BGP/MPLS IP-VPNs.

-- draft-kumaki-murai-l3vpn-rsvp-te

September 2010

IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines the PCEP extensions for the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites.

-- draft-kumaki-murai-pce-pcep-extension-l3vpn

MIPv6 Binding Updates CGA Authorization

The standard RFC 3775 mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to its Home Agent relies on the use of a pair of unidirectional IPsec security associations between these two nodes. The standard mechanism to secure Mobile IPv6 Binding Updates sent by a Mobile Node to one of its Correspondent Nodes relies on the use of a return routability test that involves the Correspondent Node verifying reachability of the Mobile Node at both its Home Address and its Care-of Address. The mechanism also requires the correspondent node to send keying material to both of these addresses. RFC 4866 specifies a standard track mecanism that allows a Mobile Node that has configured a Cryptographically Generated Address (RFC 3972) as its Home Address to secure Mobile IPv6 Binding Updates sent its Correspondent Nodes based on the properties of its Cryptographically Generated Addresses. Note that Cryptographically Generated Addresses have also been used to counter similar security issues in the context of SHIM6 (RFC 5533) and Secure Neighbor Discovery (RFC 3971.) This memo proposes a mechanism that would let a Mobile Node use a similar mechanism to secure Mobile IPv6 Binding Updates its sent to its Home Agent with a similar technique based on the use of Cryptographically Generated Addresses.

-- draft-laganier-mext-cga

Mobile IPv6 Lone Home Binding

RFC5648 extends MIPv6 with the ability for a Mobile Node to register Multiple Care-of Addresses with its Home Agent and Correspondent Node(s). RFC 5648 also introduces the notion of a Home Binding that is essentially a binding on the Home Link, where the Care-of Address is set to the Home Address of the Mobile Node. A Mobile Node uses such a Home Binding together with one or more Multiple Care-of Address binding(s) to be able to use simultaneously both the Home Link and one or more visited link(s). The description of the Home Binding in a section of RFC 5846 entitled "Returning Home: Simultaneous Home and Visited Link Operation" seems to imply that a Home Binding can only be legitimately created while returning home and maintaining simultaneous bindings on one or more visited link(s). There is however no specific reason to prevent creation of such a Home Binding when the Mobile Node is only attached to the Home Link and does not have any interface attached to a visited link. Moreover, there is a specific use case for the creation of such a Lone Home Binding. This specification explicits the use case for creation of a Lone Home Binding, and clarifies the protocol behavior of Mobile IPv6 nodes (Mobile Node, Home Agent, Correspondent Node) involved with its creation.

-- draft-laganier-mext-lone-home-binding

Flexible BGP Communities

This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accommodate IPv6, 4-byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship.

-- draft-lange-flexible-bgp-communities

NERD LISP EID Mapping Transport

LISP is a protocol to encapsulate IP packets in order to allow end sites to multihome without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of of all EID/RLOC mappings scales well to at least 10^8 entries.

-- draft-lear-lisp-nerd

RA for AFTR Element

This document specifies a new optional extension to IPv6 Router Advertisement messages to allow IPv6 routers to advertise DS-Lite AFTR addresses to IPv6 hosts (i.e., a default IPv6 route for DS-Lite traffic). The provisioning of the AFTR address is crucial to access IPv4 connectivity services in a DS-Lite context. Means to ensure reliable delivery of this information to connecting hosts is a must. Furthermore, this RA option can be used as a means to distribute DS- Lite serviced customers among a set of deployed AFTRs without requiring a central knowledge of the underlying topology and deployed AFTRs.

-- draft-lee-6man-ra-dslite

This document explains the concept of the Internet of Things and several characteristics of objects. In addition, this document investigates key technical issues and specifies problems for the IoT.

-- draft-lee-iot-problem-statement

6RD Over UDP

This memo specifies the UDP encapsulation to IPv6 Rapid Deployment (6rd) protocol which enables hosts behind unmodified Home Gateway device to access 6rd service.

-- draft-lee-softwire-6rd-udp

Deployment Considerations for DS-Lite

This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment scenarios and applicability of the Dual-Stack Lite protocol.

-- draft-lee-softwire-dslite-deployment

IPv6 Transition

The IETF has defined a number of technologies and techniques that targets the transition from IPv4 to IPv6. Documented techniques identify high level use cases and generalized options for networks. Operators may have difficulty attempting to apply the documented techniques to their networks since each network and system operates uniquely within the global Internet. Operators may require guidance on how to identify the appropriate technology, or technologies, and apply them to their specific environments. This memo describes the problem statements related to the transition of operator's networks to IPv6.

-- draft-lee-v4v6tran-problem

IPv6 Transition Cable Use Cases

This memo describes some use cases to transition to IPv6 in cable access network. This memo discusses enabling dual-stack to users over various types of network infrastructures. It also describes impacts to network, operation, CPE, and applications.

-- draft-lee-v4v6tran-usecase-cable

IPv6 Transition Cable Use Cases

This memo describes some use cases to transition to IPv6 in cable access network. This memo discusses enabling dual-stack to users over various types of network infrastructures. It also describes impacts to network, operation, CPE, and applications.

-- draft-lee-v6ops-tran-cable-usecase

Localised ECN

This document introduces analyzes of ECN(Explicit Congestion Notification)in case of congestion of local links. 3GPP adopts and specifies shared channel for multiple user equipments in a cell. Other last mile access systems (e.g. xDSL access and Frame Relay access) have to handle congestion since bandwidth multiplexing is most likely considered for reducing unnecessary cost. Therefore, congestion in access network is to inform user equipments in case of traffic congestion utilizing congestion notification concepts and similar mechanisms. Besides the argument on the congestions of access networks, this document is also to introduce the use case of Conex which might be useful for the potential Conex proposals to notify and address the congestion of wireless access network further.

-- draft-lei-ecn-localised-congestion-notification

Compression Profile for SCTP

This document is to specify the requirements to compress headers of IP/SCTP package and how ROHC mechanism compresses SCTP. Streaming Control Transport Protocol is new generation IP transport protocol which has been published in RFC2960 and updated by RFC4960. SCTP can maintain association among multiple peers, thus supports multiple homing and multiple streaming, while inherits most functions of TCP. SCTP as transport protocol has been used to carry signaling or possible user plane data in turbulence network which needs to save spectrum resource by compressing IP headers.

-- draft-lei-tsvwg-sctp-compr-requirements-profile

Relay Agent Encapsulation for DHCPv4

This document describes a general mechanism whereby DHCP relay agents can encapsulate DHCP packets that they are forwarding in the direction of DHCP servers, and decapsulate packets that they they are forwarding toward DHCP clients, so that more than one relay agent can insert relay agent suboptions into the forwarding chain.

-- draft-lemon-dhcpv4-relay-encapsulation

Seamless MPLS

This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols.

-- draft-leymann-mpls-seamless-mpls

This document describes a simple, incremental, autonomous system (AS)-based inter-domain routing architecture to solve the scalability problems of the Internet, by separation of Endpoint Identifiers (EIDs) for identifying endpoints and Routing Identifiers (RIDs) for locating endpoints in the Internet. The proposed architecture uses AS numbers as RIDs so that global routing tables can grow only with of AS numbers, thus avoiding the rapid growth driven by constantly increasing IP prefixes. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop in October 2006.

-- draft-liang-idr-aira

DNS Impl in IPv6

-- draft-licanhuang-dnsop-distributeddns

PMIP6 inter-working with WiFi AuthN

Proxy Mobile IPv6, the IETF's protocol for network-based mobility management, requires a completed and successful authentication of the mobile node before it is registered at the mobility anchor. This document describes inter-working between access authentication mechanisms, such as IEEE 802.1X, and the Proxy Mobile IPv6 protocol to enable trusted WiFi access to a network-based mobility management domain. Furthermore, the use of authentication method specific identifiers for unique identification of mobile nodes during setup and maintenance of their mobility session is described, following recommendations of related standards organizations, such as 3GPP and the WiMAX Forum.

-- draft-liebsch-netext-pmip6-authiwk

MPLS MT

This document describes the applicability and requirements for Multiprotocol Label Switching Multiple Topology (MPLS-MT). The applicability and requirements are presented from different angles. They are expressed from a customer's point of view, a service provider's point of view and a vendor's point of view.

-- draft-li-mpls-mt-applicability-requirement

savi-roaming

This document specifies the procedure for roaming over devices that implemented SAVI (Source Address Validation Improvements) device. The binding entry creating by NDP snooping can be synchronized by some mechanism.

-- draft-lin-savi-roaming-nd

Prepaid Extentions for RADIUS

This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events.

-- draft-lior-radius-prepaid-extensions

FTP considerations

The File transfer protocol, which is defined by the RFC 959, has a long history, but still being widely used. The original version of FTP specification defines IPv4 version of FTP. RFC 2428 defines IPv6 extensions of FTP, introducingEPRT 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 discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document proposes to update IPv6 FTP client's specification to make it easier to work in 6to4 scenario.

-- draft-liu-behave-ftp64

DMM

Current mobility solutions generally introduce an anchor point in the network, e.g., HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP. The anchor point is used to maintain the mapping between the stable IP address (e.g., Home address in MIPv6) and the current routable IP address (e.g., CoA in MIPv6). However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of current IP mobility mechanisms in such a flat architecture.

-- draft-liu-distributed-mobility

FTP extension for IPv4/IPv6 transition

The File transfer protocol, which is defined by the RFC 959, has a long history, but still being widely used. The original version of FTP specification defines IPv4 version of FTP. RFC 2428 defines IPv6 extensions of FTP, introducingEPRT 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 discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document proposes to update IPv6 FTP client's specification to make it easier to work in 6to4 scenario.

-- draft-liu-ftp64-extension

MIF API Extension

API (Application Program Interface) is an interface implemented by a software program that enables it to interact with other software. In IP network communication area, Socket API is the de facto standard and is widely used in many systems. Recently, multiple interfaces or multiple connection capable devices become more and more common. But due to the limitation of the default route of the host and other issues such as DNS selection etc prevent the utilization of multiple interfaces/connections benefit. Moreover, there is no API level support for the application developer to utilize the benefit of the host's multiple interfaces/connections. Starting with the requirement of MIF API extension, this document describes a new set of abstraction APIs to provide additional services to applications running on hosts attached to multiple provisioning domains. These services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues.

-- draft-liu-mif-api-extension

IKEv2 based flow control for PMIP

PMIPv6 is designed to provide network based mobility, it requries no changes to the UE. There are proposals to extend PMIPv6 to support flow mobility. Flow mobility requries the UE and the network having communication protocol to carry the flow control messages. This document proposes to use the extended IKEv2 protocol to carry the flow control messages between the UE and network.

-- draft-liu-netext-flow-pmip

Comcasts Web Notification System Design

The objective of this document is to describe a method of providing critical end user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.

-- draft-livingood-web-notification

Reqs for mlt2uni optimization

Instead of always blindly forwarding multicast/broadcast frames through a distribution tree in Trill, some optimizations can be done to convert multicast/broadcast to unicast for certain IP controlling packets. This draft shows the scenarios in which such optimizations are needed.

-- draft-liyz-trill-reqs-mlt2uni-opt

P2P Streaming for Mobile Nodes

The scenarios where a Peer-to-Peer Streaming Protocol (PPSP) contains mobile nodes need special considerations. An analysis of all the scenarios that involve mobile nodes is necessary to provide the guidelines to PPSP protocol design and applicability. This document describes some key issues for a PPSP network with mobile nodes, and proposes some additional requirements for PPSP to handle these scenarios.

-- draft-lu-ppsp-mobile

IPv6 ND Scalability

Server virtualization allows one physical server to support many virtual machines (VMs) so that multiple hosts (20, 30, or hundreds) can be running from one physical platform. As virtual machines are introduced into a Data Center, the number of hosts within the data center can grow dramatically, which can have tremendous impact on the network and hosts. This document provides an analysis of the scalability of IPv6 Neighbor Discovery (RFC 4861) in data centers with a large number of virtual machines.

-- draft-mackcrane-armd-ipv6-nd-scaling

draft-madi-dhc-dhcpv6-psac-00

IPSec [RFC2401]is pervasive in many scenarios to build the channel of security mechanism to protect the communication between the host and the local servers, such as DNS recursive name server [RFC1304]. In the public wireless access environment, an extra trust relationship configuration between the roaming host and the local server, manually or by IKE [RFC2409], is indispensible. DHCP is typically the first protocol executed by a mobile host when it enters a new network, so this document present an extension to DHCPv6 to piggyback the parameters needed for IPSec, avoiding the delay invited by manual configuration of security association or IKE interaction for IPSec.

-- draft-madi-dhc-dhcpv6-psac

DS-Lite RADIUS Extensions

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix. DS-Lite requires to pre-configure the AFTR tunnel information on the B4 element. In many networks, the customer profile information may be stored in AAA servers while client configurations are mainly provided through DHC protocol. This document specifies two new RADIUS attributes to carry Dual-Stack Lite Address Family Transition Router (AFTR) IPv6 address and name; the RADIUS attributes are defined based on the equivalent DHCPv6 options already specified in draft-ietf-softwire-ds-lite-tunnel-option. These RADIUS attributes are meant to be used between the RADIUS Server and the NAS, they are not intended to be used directly between the B4 element and the RADIUS Server.

-- draft-maglione-softwire-dslite-radius-ext

RFC5787bis

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258.

-- draft-malis-ccamp-rfc5787bis

LwIP Stack Analysis

This document analyzes the main implementation of lightweight IP stack over constrained platform, including Contiki, TinyOS, and Atmel RUM approach. The consideration for lightweight IP stack implementation is summarized. The target of this document is to facilitate the ongoing/future developers on lightweight IP stack and provide guideline for lightweight IP stack implementation by documenting the related techniques.

-- draft-ma-lwip-stack-analysis

Geo-Location extensions in MRT

This document extends the Border Gateway Protocol (BGP) MRT export format for routing information with terrestrial coordinates.

-- draft-manderson-grow-geomrt

GUT

Deploying new transport protocols on the Internet is a well-known problem, as NATs and firewall drop packets with e.g. new protocol types or unidentified TCP options. Tunnelling over UDP is one way to make IP packets hide the actual payload and enable end-to-end delivery. This document proposes a simple UDP tunnelling encapsulation and end-host operation to enable new (and old) IP payloads, e.g., new transport protocols, to be deployed on the Internet.

-- draft-manner-tsvwg-gut

PCEP Ext for GMPLS

This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane.

-- draft-margaria-pce-gmpls-pcep-extensions

Optical Impairment Signaling

The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility.

-- draft-martinelli-ccamp-optical-imp-signaling

draft-martocci-6lowapp-building-appns-00

Building management systems have evolved toward IP communication at the enterprise level during the past decade. IP implementation at the real-time control and sensor layers would provide a single pervasive protocol usable across the entire system increasing flexibility and code reuse. This document will describe the topology of these building networks, the application protocols widely used in their deployment and the application use cases. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 8, 2011. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

-- draft-martocci-6lowapp-building-applications

ConEx Concepts and Abstract Mechanism

This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver may pass this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in- band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management.

-- draft-mathis-conex-abstract-mech

SA46T applicability

This document provide IPv6 transition scenario using Stateless Automatic IPv4 over IPv6 Tunneling (SA46T) and applicability of SA46T. SA46T is just one of automatic tunnling technologies, so there are several usage with SA46T. This document shows such possible applicability.

-- draft-matsuhira-sa46t-applicability

SA46T-AS

This document specifies Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing (SA46T-AS) base specification. SA46T-AS is basically the same technology with SA46T, however that have IPv4 address sharing capability. SA46T-SA is gateway technology, not protocol.

-- draft-matsuhira-sa46t-as

SA46T gaddr

This document proposes Stateless Automatic IPv4 over IPv6 Tunneling (SA46T) Global Address Format. SA46T can apply to organization's network individually, but if coordination between the organizations made, the total number of times of encapsulations and decapusulations can be reduced. That coordination is achieved by using same SA46T address format, that is Global address. This document proposes SA46T Global address format. SA46T is a gateway technology, not protocol. But SA46T Global Address needs IANA assignment, so this document should be categorized standard track or experimental.

-- draft-matsuhira-sa46t-gaddr

SA46T spec

This document specifies Stateless Automatic IPv4 over IPv6 Tunneling (SA46T) base specification. SA46T makes backbone network to IPv6 only. And also, SA46T can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. SA46T is gateway technology, not protocol.

-- draft-matsuhira-sa46t-spec

MIKEY-TICKET

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Such deployments are gaining in interest. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.

-- draft-mattsson-mikey-ticket

IPPS URI Scheme & Transport Binding

This memo defines the IPPS URI scheme and the corresponding IPP over HTTPS transport binding. This memo updates the Internet Printing Protocol/1.1 Model and Semantics (RFC 2911), by extending section 4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'. This memo updates the Internet Printing Protocol/1.1 Encoding and Transport (RFC 2910), by extending section 4 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using IPP with TLS'. This memo complements (but does not update) the Internet Printing Protocol/1.1 IPP URL Scheme (RFC 3510). This memo is a product of the Internet Printing Protocol Working Group in the IEEE-ISTO Printer Working Group, as part of their IPP Everywhere project for mobile, driverless, ubiquitous printing. An IPPS URI is used to specify the network location of a secure print service that supports the IPP/1.1 Model and Semantics (RFC 2911), or of a network resource (for example, a print job) managed by such a secure print service.

-- draft-mcdonald-ipps-uri-scheme

This draft proposes some use cases for inclusion in the conex Working group charter's deliverable for an informational RFC covering use case description. These use cases are in addition to and/or complement those described in [UseCases], and focus on forms of congestion exposure that involve resources other than queues and timeframes other than real-time.

-- draft-mcdysan-conex-other-usecases

SDP Descriptors for FLUTE

This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions.

-- draft-mehta-rmt-flute-sdp

Logical Interface Support

A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is desirable on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyses the issues around it when used in context with various mobility management features.

-- draft-melia-netext-logical-interface-support

PCN-based AC Using Implicit Probing

Pre-congestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. This document proposes an admission control method. It assumes that PCN nodes perform threshold-marking configured with the PCN- admissible-rate on any link. The decision point uses the PCN marking state of an initial signaling message of a flow to determine whether the flow should be admitted or blocked.

-- draft-menth-pcn-implicit-probing

sdiff-vnemo

A mobile network can be multihomed as described in [RFC4980]. This document describes the experimental result of service differentiation using multihoming with multiple prefixes. The multiple prefixes in IPv6 NEMO implements multiple virtual mobile networks on a single physical NEMO. Then, service differentiation can be achieved using several virtual mobile networks that exist on a single mobile network. As a result, this configuration can be used for service differentiation for each mobile network node inside the mobile network by prioritizing among the virutal mobile networks or forwarding traffic from each virtual mobile network to different access networks. In this experiment, a mobile router with multiple interfaces can make connection to several access networks simultaneoulsly.

-- draft-mext-park-vnemo

LISP Mobile Node

This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes.

-- draft-meyer-lisp-mn

Overview of OAM Mechanisms

Operations, Administration, and Maintenance (OAM) is a general term that refers to detecting and reporting link failures. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF, as well as a comparison to other OAM mechanisms that have been defined by the IEEE and ITU-T.

-- draft-mizrahi-opsawg-oam-overview

October 2010

The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. This document defines a mechanism that allows an access network to provide IP connectivity modes hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to allow the EAP peer in executing in a reliable and efficient manner the IP connectivity step as soon as the authentication phase completes. This is useful in situations where a peer and the networks it visits support various IP connectivity modes. Without the hint, such a peer might fail or take some time to select a valid IP connectivity mode on the visited network. With the help of the hint, a visited network provides the peer with a list of supported IP connectivity modes and allows it to execute successfully the convenient IP connectivity as soon as the authentication is complete. The hint is particularly useful when users are performing vertical handovers through different network technologies such as wireless ones.

-- draft-mongazon-emu-ip-modes-eap

TCP Rehash

The present specification describes a light extension of the TCP protocol [RFC793] that allows a TCP transport connection to be maintained operational whenever the underlying IP network address of its end-points changes. This includes situations where a single- interface host changes its IP address or where a multiple-interface host diverts a connection from one interface to another. The mechanism used to maintain a transport connection in such situations is based on the capability of both end-points to "Rehash" a TCP connection (rebuild its lookup key) with a new IP address in a fast and reliable manner.

-- draft-mongazon-tcpm-tcp-rehash

DPWS for 6LoWPAN

This draft describes adaptions and enhancements for deploying the Devices Profile for Web Service (DPWS) in 6LoWPAN networks.

-- draft-moritz-6lowapp-dpws-enhancements

Policy Considerations

Without doubt the Internet infrastructure developed far beyond the expectations of the original funding agencies, architects, developers, and early users. The society's current use and expectations often lead to the need to take the economical and political context in which technology is deployed into consideration. This document aims to make protocol designers aware of the public policy-related questions that may impact standards development. This document contains questions, as opposed to guidelines or strict rules that should in all cases be followed. This document provides a framework for identifying and discussing questions of public policy concern and serves as an umbrella for related policy documents.

-- draft-morris-policy-cons

Host Identity Protocol Architecture

This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

-- draft-moskowitz-hip-rfc4423-bis

Host Identity Protocol

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

-- draft-moskowitz-hip-rfc5201-bis

HIP Diet EXchange (DEX)

This document specifies the details of the Host Identity Protocol Diet EXchange (HIP DEX). HIP DEX is a variant of the HIP Base EXchange (HIP BEX) [RFC5201-bis] specifically designed to use as few crypto primatives as possible yet still deliver the same class of security features as HIP BEX. The design goal of HIP DEX is to be usable by sensor devices that are code and processor constrained. Like HIP BEX it is expected to be used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP). HIP DEX can also be used directly as a keying mechanism for a MAC layer security protocol as is supported by IEEE 802.15.4 [IEEE.802-15-4.2006].

-- draft-moskowitz-hip-rg-dex

Remote DHCPv6 Autoconfiguration

This document describes remote autoconfiguration mechanism, an extension to DHCPv6 protocol. Every time a node attaches to a new link, it must renew or obtain new address and parameters, using DHCPv6 protocol. For mobile nodes it is beneficial to obtain address and other configuration parameters remotely, before actually attaching to destination link. This document defines mechanism using remote configuration and new options required to remotely discover destination DHCPv6 servers. Remote unicast communication with DHCPv6 servers is also defined.

-- draft-mrugalski-remote-dhcpv6

DHCPv6 server-side DAD

This document defines new way of performing DAD procedure. DHCPv6 maintain small pool of unique addresses. DHCPv6 server performs DAD procedure for each address, before populating this uniqueness verified pool. Client may ask for an address that already passed DAD test, thus speeding up client configuration process.

-- draft-mrugalski-server-dad-dhcpv6

DVNE Framework

This document discusses the management and configuration requirements for large Virtual Networks (VNs). VNs are private networks that employ tunneling technologies to overlay private network links over physical IP networks. As VNs grow, the amount of administrative effort required to manually configure virtual nodes and to set up the required tunnels becomes prohibitive. The DVNE protocol automates this process, elminating much of the administrative work involved in setting up a virtual network.

-- draft-mrw-dvne-fw

NAT66

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Address Translation (NAT66) function that provides the address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while minimizing, but not completely eliminating, the problems associated with NAT44.

-- draft-mrw-nat66

Enhanced Fast Handover

In MIPv6 [1], whenever a mobile node changes its attached point, handover process should be followed to inform its home agent and correspondent of a MN's current location. The handover process is decomposed into layer 2 and layer 3 handovers again, and these two handovers are accomplished sequentially, which causes long latency problem. This problem is a critical issue in MIPv6. To make up for this, we propose an enhanced Fast Handover scheme to reduce the overall latency on handover, revising the Fast Handover [2]. Especially, several messages in layer 3 are sent in one frame during layer 2 handover.

-- draft-mun-mipshop-efh-fast-mipv6

October 2010

In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that support fast macro mobility handover. These fast handover schemes can reduce both the handover latency and the pakcet loss. The schemes described in this document adopt the fast handover of FMIPv6 protocol to the edge access routers in MAP domains. The schemes support two fast handover modes for macro mobility handover in HMIPv6.

-- draft-mun-mipshop-fhmacro

SIPCLF - IPFIX

This draft defines a log file format conforming to the information model defined in the SIP-CLF problem statement based upon the IPFIX File Format. It details the creation and interpretation of these files, and provides examples based on common SIP situations.

-- draft-niccolini-sipclf-ipfix

ISIS MI MIB

This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this draft describes a MIB for the IS-IS Routing protocol that allows a single router to share one or more links among multiple IS-IS routing protocol instances

-- draft-nie-isis-mi-mib

Flow Monitoring Benchmarking

This document provides methodology and framework for quantifying performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired and exported as the performance metric. The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470].

-- draft-novak-bmwg-ipflow-meth

OSPF Hybrid Broadcast and P2MP Intf Type

This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.

-- draft-nsheth-ospf-hybrid-bcast-and-p2mp

SRS

This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. A bespoke XML format is used to communicate between clients and the SRS server. Comments are solicited and should be addressed to the author: matt@nzrs.net.nz

-- draft-nzrs-srs

draft-oflynn-6lowpan-icmp-hc

Compression for ICMPv6 Messages, specifically designed for 6lowpan-nd.

-- draft-oflynn-6lowpan-icmphc

draft-oflynn-core-bootstrapping

The Internet of Things is marching its way towards completion. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operation of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication.

-- draft-oflynn-core-bootstrapping

PANA Key Wrap

This document specifies an extension to PANA (Protocol for carrying Authentication for Network Access) for secure delivery of keys from a PAA (PANA Authentication Agent) to a PaC (PANA Client).

-- draft-ohba-pana-keywrap

PANA Relay Element

This document specifies PANA (Protocol for carrying Authentication for Network Access) Relay Element functionality which enables PANA messaging between a PaC (PANA Client) and a PAA (PANA Authentication Agent) where the two nodes cannot reach each other by means of regular IP routing.

-- draft-ohba-pana-relay

TPA-Label

A third party authorization label (TPA-Label) is a DNS-based extension for DKIM ADSP records that allows domains in the From header field to authorize acceptable third-party signatures. This approach allows autonomous and unilateral authorizations for third- party domains using scalable, individual DNS transactions. The extended scope of DKIM signing practice assertions introduced here supplants transparent authorization schemes that are more difficult to administer. Alternatives for facilitating third-party authorizations currently necessitate coordination between two or more domains to synchronously set up selector/key DNS records, DNS zone delegations, and/or a regular exchange of public/private keys. Checking TPA-Label Resource Records for signing practices might occur infrequently when a message is not compliant with restrictive ADSP practices, where an Author Domain Signature is either missing or invalid. When a third-party signature is found, TPA-Label Resource Record transactions offer an efficient means for Author Domains to authorize specific third-party signing domains. Recipients are afforded a method to determine whether authorization exists in situations where other modes of authorization are impractical. TPA- Label Resource Records permit Author Domains a means to influence message handling selectively, for messages otherwise lacking valid Author Domain signatures.

-- draft-otis-dkim-tpa-label

draft-palanivelan-bfd-v2-gr-08.txt

This document proposes an extension for Bidirectional Forwarding Detection (BFD) to support Graceful Restart, in complementing Graceful Restart support of the underlying protocol.This would work consistently, irrespective of the bfd mode or protocol or the type of restart and, most importantly, the vendors design and implementation. This document describes in detail the challenges to BFD in surviving a graceful restart, and a generic solution to such challenges.

-- draft-palanivelan-bfd-v2-gr

BGP Convergence Methodology

BGP is widely deployed and used by several service providers as the default Inter AS routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP Benchmarking Methodology using existing BGP Convergence Terminology, RFC-4098. 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 April 18, 2009.

-- draft-papneja-bgp-basic-dp-convergence

Multi-path routing solution

This document discusses the use of multiple interfaces of Mobile Ad hoc NETworks (MANETs) nodes and multiple path MANET routings protocols with respect to traditional, single network interface based ones. It then describes the design principles and methods of multiple path routing over MANET nodes with multiple interfaces.

-- draft-park-manet-multipath-analysis-scenarios

Extension of Hierarchical Mobile (E-HMIPv6) for

This document describes an extension to the Hierarchical Mobile IPv6 for multiple tunnel support by adopting an IP mobility management scheme in which multiple wireless network interfaces are assigned active IPv6 care-of addresses and are used simultaneously to enable fast handover. The mechanism of this document not only enhances the handover latency, but also drastically reduces the packet loss and improves throughput. Multiple Tunnel Support November 2010

-- draft-park-mext-multipletunnel

PMIPv6 multihoming using 2-level prefixes

This document discusses the use of multiple interfaces in mobile host. Especially, Horizontal handover and flow handover in 2-level prefix model are resolved.

-- draft-park-multihoming-ext-pmipv6-2level-prefix

IPsec issues with 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.

-- draft-patil-mext-mip6issueswithipsec

ALTO and IPv4/IPv6

IPv4/IPv6 co-existence and transition is topic or great discussion and interest. In order to deal with IPv4 depletion ISPs have some techniques at their disposal such as Carrier Grade NAT , DS-Lite and 6rd. As this techniques get deployed, they change the topology of the network by creating gateways or overlays which in the end affect how ALTO might work. This draft discusses such impacts and possible solutions.

-- draft-penno-alto-ipv4v6

Analysis of 64 Translation

Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

-- draft-penno-behave-64-analysis

MANET leghost autoconfiguration

This document describes methods by which a host running only DHCPv6 or Neighbor Discovery can obtain an address suitable for use in an ad hoc network.

-- draft-perkins-autoconf-leghost

MN Identifier Types for RFC 4283

Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283).

-- draft-perkins-mext-4283mnids

GTP Tunnel Request for Mobile IPv6

Widely deployed mobility management systems for wireless communications use GTP for transmitting packets to mobility agents serving the mobile node. In order to enable use of Proxy Mobile IPv6 in such telecommunication systems, GTP should be allowed as a tunneling choice for packets between the LMA and the MAG. This specification allocates a new bit (the 'G' bit) in the Proxy Binding Update for the purpose of enabling GTP tunneling.

-- draft-perkins-mext-gtpdata

Alternate Home Agent Tunnel

Widely deployed mobility management systems for wireless communications have isolated the path for forwarding data from the control plane signaling for mobility management. To realize this requirement with Mobile IP requires that the control functions of the home agent be addressable at a different IP address than the source IP address of the tunnel between the home agent and mobile node. Similar considerations hold for mobility anchors implementing Hierarchical Mobile IP or PMIP.

-- draft-perkins-mext-hatunaddr

TURN URIs

This document defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [TURN-RESOLV].

-- draft-petithuguenin-behave-turn-uri-bis

RA-based Routing

This draft specifies extensions to the ICMPv6 Router Advertisement messages and processing. Traditionally, prefixes contained in RAs are used for on-link determination, on-link address auto- configuration, but not for path setup towards multi-hop destinations. The extensions proposed here still rely on RAs being communicated on a single link (not across several IP hops), but upon RA reception the prefixes are installed in the routing table; they are thus used for forwarding packets further than a single link (multi IP hop).

-- draft-petrescu-autoconf-ra-based-routing

DCB Benchmarking

Existing benchmarking methodologies are based on the assumption that networking devices will impartially drop network traffic at their performance limits. Data Center Bridging (DCB) devices, however, will attempt to throttle prioritized traffic from network endpoints before those limits are reached in order to minimize the probability of frame loss for high value traffic. Hence, existing methodologies based around indiscriminate frame loss are inappropriate for DCB devices. This document takes the basic benchmarking ideas based on loss and extends them to support "lossless" Ethernet devices.

-- draft-player-dcb-benchmarking

RSVP APP-ID Profiles

RFC 2872 defines an Resource Reservation Protocol (RSVP) object for application identifiers. This document uses that App-ID and gives implementers specific guidelines for differing voice and video stream identifications to nodes along a reservation path, creating specific profiles for voice and video session identification.

-- draft-polk-tsvwg-rsvp-app-id-vv-profiles

Extension to PCEP for Enhanced errors

This document defines new error and notification types and codes for the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft extends error and notification types in order to associate predefined PCEP behaviors.

-- draft-pouyllau-pce-enhanced-errors

DS-Lite Multicast

The DS-Lite technique enables service providers to deliver IPv4 unicast services following IPv4 address exhaustion by combining two mechanisms: NAT and IPv4-in-IPv6 encapsulation. This document describes extensions to DS-Lite to support IPv4 multicast delivery.

-- draft-qin-softwire-dslite-multicast

Lightweight Secure Router

When a sensor node roams within a very large and distributed wireless sensor network, which consists of numerous sensor nodes, its routing path and neighborhood keep changing. In order to provide a high level of security in this environment, the moving sensor node needs to be authenticated to new neighboring nodes as well as to establish a key for secure communication. The document proposes an efficient and scalable protocol to establish and update the secure key in a dynamic wireless sensor network environment. The protocol guarantees that two sensor nodes share at least one key with probability 1 (100%) with less memory and energy cost, while not causing considerable communication overhead.

-- draft-qiu-6lowpan-secure-router

LSF Registry

In the past Mandatory Access Control(MAC) systems have used very rigid policies which were hardcoded into the particular protocol and platform. As MAC systems are more widely deployed additional flexibility in mechanism and policy is required. Where traditional trusted systems implemented Multi-Level Security and integrity models, modern systems have expanded to include technologies such as type enforcement. Due to the wide range of policies and mechanisms it has proven through past efforts to be virtually impossible to accomodate all parties in one security label format and model. To accomodate multiple MAC mechanisms and label formats this document proposes a registry of label format specifications. This registry contains several identifiers to accomodate both integer and string preferences and associates those identifiers with an extensive document outlining the exact syntax and use of the particular label format.

-- draft-quigley-label-format-registry

draft-raggarwa-mpls-seamless-mcast-01.txt

This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used. The applications/services that use such an inter- area service LSP may be BGP MVPN, VPLS multicast or Internet multicast over MPLS.

-- draft-raggarwa-mpls-seamless-mcast

draft-raggarwa-sajassi-l2vpn-evpn-01.txt

This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN).

-- draft-raggarwa-sajassi-l2vpn-evpn

Group Communication for CoAP

This is a working document intended to trigger discussion and develop draft language for the CoAP protocol specification in the area of group communication (including multicast functionality). Engineering tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics that may impact or be impacted by design choices in the subject area.

-- draft-rahman-core-groupcomm

Cognitive Adaptive Module (CAM)

This document describes a generic Cognitive Adaptive Module (CAM) that can be utilized in conjunction with Mobile Ad hoc Network (MANET) routing protocols. The main concept behind CAM is the fact that the provisioning of multimedia communications traditionally requires routing Quality of Service (QoS) guarantees [9]. Such a task is NP Complete in MANETs when QoS optimization is subject to more than one parameter [9]. Hence, the provisioning of soft QoS guarantees for effective and efficient routing in dynamic environments, as specified in [1], is the best alternative. However, the latter cannot be optimally achieved by using a single metric based path selection process or routing approach due to variations in both upper layer service QoS requirements and situational constraints. CAM provides interfaces to routing components such that protocols can be segmented into these components and can be easily made configurable and adaptive. For instance, the route selection process can be done in an adaptive manner to satisfy the requirements for effective and efficient routing. This is achieved by providing interfaces from the CAM core to various user defined components (e.g. Repositories Component) such that all components and component parts (e.g. DYMO reactive routing logic) can inter- communicate.

-- draft-ramrekha-manet-cam

This document describes the ChaMeLeon (CML) routing protocol designed for Mobile Ad hoc NETworks (MANETs) supporting emergency communications. CML is a hybrid and adaptive routing protocol operating within a defined disaster area denoted as the Critical Area (CA). The main concept behind CML is the adaptability of its routing mechanisms towards changes in the physical and logical state of a MANET. For autonomous emergency communications, there is a likelihood that the network size will vary whenever more rescuers join or leave the network. In addition, battery exhaustion of lightweight mobile communication devices used by rescuers could stipulate another reason for changes in the network size. Hence, this version of CML adapts its routing behavior according to changes in the network size within a pre-defined CA. For small networks, CML routes data proactively using the Optimized Link State Routing (OLSR) protocol whereas for larger networks it utilizes the reactive Ad hoc On-Demand Distance Vector (AODV) Routing protocol so that overall routing performance is improved. These transitions occur via the CML oscillation phase. This document focuses on the description of the processes involved in the CML Cognitive and Adaptive Module (CAM), CML Oscillation phase and transition between phases.

-- draft-ramrekha-manet-cml

bgp-optimal-route-reflection

[RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments.

-- draft-raszuk-bgp-optimal-route-reflection

LDP IP and PW Capability

Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces it "incapability" or disability or non-support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over established LDP session.

-- draft-raza-mpls-ldp-ip-pw-capability

draft-rekhter-pim-sm-over-mldp-02.txt

When IP multicast trees created by PIM-SM in ASM mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switches Paths are established using mLDP.

-- draft-rekhter-pim-sm-over-mldp

draft-rekhter-rfc4760bis-01.txt

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.

-- draft-rekhter-rfc4760bis

OSPF Incremental LSDB Sync

The ability of OSPF to transport non-routing information to be used by other applications was defined by the Opaque LSA Option. In order to not impact the convergence of routing information, this document describes a simple process to incrementally synchronize the routing and non-routing information residing in an OSPF link-state database.

-- draft-retana-ospf-ils

RPKI Local TA Management

This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document.

-- draft-reynolds-rpki-ltamgmt

RPKI_Alg_Agility

This document specifies the process that Certificate Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified.

-- draft-rgaglian-sidr-algorithm-agility

ILNP ICMP

This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG.

-- draft-rja-ilnp-icmp

ILNP Intro

This document describes the Concept of Operations for the Identifier Locator Network Protocol (ILNP), which is an experimental extension to IP. This is a product of the IRTF Routing RG.

-- draft-rja-ilnp-intro

ILNP Nonce

This document describes an experimental Nonce Destination Option that is part of the Identifier Locator Network Protocol (ILNP). This option is used with the ILNP variant that is based upon IPv6. This is a product of the IRTF Routing RG.

-- draft-rja-ilnp-nonce

Flow State Aware Signaling

The concepts in this document are based on work on Q.Flowstatesig in the ITU SG11/Q5. Flow State Aware Signaling has been worked on in the ITU for the past 13 years. However, this document stands on its own since no IETF compatible format has yet been adopted. The goal of this protocol is to provide (1) a technique to have network nodes provide available rate flows (like TCP) rapid and periodic feedback to the sender as to the maximum rate they should send and (2) to provide network feedback to fixed rate flows (like UDP voice) if the peak rate they require can be statistically assured. Network traffic using this protocol should experience reduced response time, less queuing delay and less packet discards. The use of this protocol is limited to bounded subnets at the network edge and is to be converted to and from standard IP flows at the subnet boundaries.

-- draft-roberts-fsasignaling

ANCP NAS MIB

This memo defines a portion of the Management Information Base (MIB) for managing NAS (Network Access Server) that are using Access Node Control Protocol (ANCP).

-- draft-rohit-ancp-nas-mib

draft-rosen-l3vpn-mvpn-wildcards-01.txt

In the procedures for Multicast Virtual Private Networks, individual customer multicast flows can be assigned to specific multicast tunnels through a service provider network. This document specifies the encoding and semantics of "wild card selectors", which can be used to assign certain sets of customer multicast flows as a group to specific multicast tunnels.

-- draft-rosen-l3vpn-mvpn-wildcards

draft-rosen-l3vpn-spmsi-joins-mldp-01.txt

The specification for Multicast Virtual Private Networks (MVPN) contains an option that allows UDP-based "S-PMSI Join" messages to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification so that these options can be used when the tunnel through the provider's network are Point-to-Multipoint Label Switched Paths.

-- draft-rosen-l3vpn-spmsi-joins-mldp

RANGERS

Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) [RFC5720] provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.

-- draft-russert-rangers

Service Identity

Many application technologies enable a secure connection between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application services in such interactions.

-- draft-saintandre-tls-server-id-check

November 2010

This document defines new four options of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to carry a set of configuration information related to the Kerberos protocol [RFC4120].

-- draft-sakane-dhc-dhcpv6-kdc-option

NAT64 for DSMIPv6

This memo specifies how IPv6 only mobile nodes (MN) receiving host- based mobility management using Dual Stack Mobile IPv6 (DSMIPv6) can communicate with IPv4 only servers. The protocol is based on home agents maintaining a table similar to NAT64 and linking it to the binding cache. This technique avoids the problems encountered when NAT64 is used for mobile nodes in Dual Stack Mobile IPv6. How IPv6 only mobile nodes can receive multicast data from IPv4 only content providers is also explained.

-- draft-sarikaya-behave-mext-nat64-dsmip

draft-sarikaya-core-sbootstrapping

The Internet of Things is marching its way towards completion. Nodes can use standards from the 6LoWPAN and ROLL WG to achieve IP connectivity. IEEE Standards ensure connectivity at lower layers for resource-constrained devices. Yet a central problem remains at a more basic layer without a suitable answer: how to initially configure the network. Without configuration the network never advances beyond a large box of nodes. Current solutions tend to be specific to a certain vendor, node type, or application. This document outlines exactly what problems are faced in solving this problem. General problems faced in any low-power wireless network are outlined first; followed by how these apply to bootstrapping. A selection of currently proposed techniques is presented. From these a more generic approach is presented, which can solve the problem for a wide range of situations. An emphasis is on performing this bootstrapping in a secure manner. This document does not cover operation of the network securely. This document does provide the basis for allowing the network to operate securely however, by providing standard methods for key exchanges and authentication.

-- draft-sarikaya-core-sbootstrapping

LSEND for LLN

This document defines lightweight secure neighbor discovery for low- power and lossy networks. The nodes generate a Cryptographically Generated Address using an Elliptic Curve Cryptography public key, register the Cryptographically Generated Address with a default router and periodically refresh the registration. Modifications to 6lowpan Neighbor Discovery protocol are described for secure neighbor discovery for low-power and lossy networks. Cryptographically generated address and digital signature are calculated using elliptic curve cryptography public key of the node.

-- draft-sarikaya-lwip-cgand

DHCPv6 Solution

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.

-- draft-sarikaya-mif-dhcpv6solution

Prefix Delegation

As interest on IPv6 deployment is increasing in cellular networks several migration issues are being raised and IPv6 prefix management is the one addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we address prefix management issues such as the access router offloading delegation and release tasks of the prefixes to a DHCPv6 server using DHCPv6 PD. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next stateless or stateful address allocation to the mobile node, e.g. with a Router Advertisement or using DHCP. We also describe prefix management using Authentication Authorization and Accounting servers.

-- draft-sarikaya-v6ops-prefix-delegation

LISP Iterable Mappings

The Mapping System is a key component of the Locator Identifier Separation Protocol (LISP). In this document, we describe Iterable Mappings allowing the mappings to point to Map-Server addresses instead of ETR addresses. Iterable mappings open the possibility of performing iterative queries that could be used to deploy mapping systems without requiring overlays or to optimize current mapping systems.

-- draft-saucez-lisp-iterable-mapping

LISP Security

This draft analyses some of the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks.

-- draft-saucez-lisp-security

Heuristic NAT64 discovery

Advanced hosts and applications benefit of the knowledge of an IPv6 address, AAAA record, synthesis taking place in the network. This draft describes a method for detecting presence of NAT64 and for learning Network-Specific Prefix used in the access network without support from the access network. The method depends on existence of known IPv4-only domain name. The information learned enables applications and hosts to to perform local IPv6 address synthesis and in some cases avoid NAT64.

-- draft-savolainen-heuristic-nat64-discovery

MIF and DNS server selection

A multi-homed node can be connected to multiple networks that may utilize different DNS namespaces. The node often receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When the multi-homed node needs to utilize DNS, it has to choose which of the servers to contact to. This document describes a policy based method for helping on selection of DNS server for both forward and reverse DNS lookup procedures with help of DNS suffix and IPv6 prefix information received via DHCPv6.

-- draft-savolainen-mif-dns-server-selection

MPTCP API

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP.

-- draft-scharf-mptcp-api

Multi-Connection TCP

Multipath transport over potentially different paths can be realized by several coupled Transmission Control Protocol (TCP) connections. Multi-Connection TCP (MCTCP) transport aggregates multiple TCP connections between potentially different addresses into a single session that can be accessed by an application like a single TCP connection. MCTCP encodes control information, as far as possible, in the payload of the TCP connections and therefore requires only minor changes in the TCP implementations, and it is transparent in the single-path case. MCTCP is therefore proposed as a simple, modular, and extensible mechanism for multipath transport.

-- draft-scharf-mptcp-mctcp

Multicast for FMIPv6/PFMIPv6

Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latencies. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and will benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations.

-- draft-schmidt-multimob-fmipv6-pfmipv6-multicast

DHC Options for Network Management

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that provide a list of IP addresses that can be used to locate network management services.

-- draft-schoenw-opsawg-nm-dhc

LISP MIB

This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics.

-- draft-schudel-lisp-mib

Unauthenticated Emergency Service

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.

-- draft-schulzrinne-ecrit-unauthenticated-access

RPL MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the IPv6 Routing Protocol for Low power and Lossy Networks (RPL).

-- draft-sehgal-roll-rpl-mib

Connection Manager requirements

It is a common practice for multiple interface terminals to use a connection manager to perform provisioning domain selection and interface configuration. The concept of connection managers for personal computers is well known, and similar logic is now common in mobile phones that have multiple radio interfaces [3GPP TS 23.402]. The Problem Statement document highlights the lack of standardized behavior for terminals in regard to managing multiple interfaces and their respective properties. To address this issue, this document proposes a set of functional requirements for a generic MIF Connection Manager.

-- draft-seite-mif-connection-manager

The EAP-EKE Method

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates.

-- draft-sheffer-emu-eap-eke

Traceroute Extension

This document specifies an extension to traceroute and ping messages that allows the probe packets to be authenticated by the intermediate nodes and the destination node. This extension can also include requests for node specific information that the probe sender is interested to receive from one or more nodes via the traceroute and ping replies. This extension supports UDP, TCP and ICMP types of traceroute and ping probes.

-- draft-shen-traceroute-ping-ext

Network Portability

Recent progress of virtual machine technology made it possible to host various Internet service nodes in a so called cloud environment. The virtual machine hosting technology provides a method to migrate a virtual machine from one hypervisor to another. However, such a technology is mainly focusing on a migration between hypervisors attached to the same link, and tend not to consider migration over the Internet. This document mentions the purpose of that type of operation and describe several possible operation methods to provide network portability in cloud systems.

-- draft-shima-cloud-net-portability-reqs-and-models

ISP Shared Address

This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6.

-- draft-shirasaki-isp-shared-addr

NAT444

This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence.

-- draft-shirasaki-nat444

NAT444 addressing models

This document describes addressing models of NAT444. There are some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document helps network architects to use NAT444 after IPv4 address exhaustion.

-- draft-shirasaki-nat444-isp-shared-addr

OSPFv3 Stub Router Advertisement

OSPFv3 accommodates for the possibility to indicate through the R-bit if a router is an active router and should be taken into consideration as a transit device. Another method available is the v6-bit indicating if a router or link should be excluded from IPv6 routing calculations. A direct result is that OSPFv3 has "no transit capability" potentially based upon the setting of R-bit and V6-bit, unlike the stub OSPFv2 router functionality. This feature proposal has as purpose to re-introduce existing OSPFv2 stub router behavior into OSPFv3 to keep the operational service provider experience used to deploy, troubleshoot and be familiar with OSPFv2 stub routing. OSPFv3 has similar metric field information field of all of LSAs, with exception of the Link-LSA, so RFC3137 method can be re-utilized in OSPFv3. To drive consistency between OSPFv2 and OSPFv3, there should be next to supporting both R-bit and v6-bit be support for"max-metric".

-- draft-shishio-ospf-ospfv3-stub

Dec 2010

This document introduces a dynamic secondary routing structure with the destination address and subnet mask as the first index and DSCP value as the second. DSCP values of various applications are extracted and packets are forwarded in accordance with them. Therefore, applications with different demands of Quality of Service (QoS) can be served accordingly, which can promote the quality of transmission and finally achieve differentiated services.

-- draft-shunyi-secondary-routing-structure

MSHN and IPv6

This document tries to address an approach for reorganization of entire network in a large address space. It describes how a three- tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6. This document also tries to come out with an approach how IP switch based network can perform as good as ATM network for the processing of real time traffic.

-- draft-shyam-mshn-ipv6

September

This document proposed a network-based mobility control scheme in wireless/mobile networks using the Locator-Identifier Separation Protocol (LISP). In the existing host-based mobility control, LISP Tunnel Router (TR) is implemented at mobile node. In the proposed scheme, each TR is implemented at the first-hop access router that mobile nodes are attached to in the wireless network. For network- based mobility control, we present the data delivery and handover control operations. It is expected that the proposed network-based scheme can reduce implementation overhead and handover latency of MN, compared to the existing host-based scheme.

-- draft-sichoi-lisp-ar

NEMO Support in the PMIPv6 Domain

Network mobility (NEMO) enables all the nodes within a mobile network to provide session continuity without requiring their involvement when the mobile network moves. To provide NEMO support, the NEMO basic support protocol (NEMO-BSP) is specified in [RFC 3963]. With the advances of the network-based mobility management protocol referred to as Proxy Mobile IPv6 (PMIPv6), interest in applicable NEMO support in the PMIPv6 domain is increasing however, the standard PMIPv6, defined in [RFC 5213], handles only a single mobile node. This document presents a NEMO-enabled PMIPv6 using a Proxy Router (PR) rather than the MR defined in [RFC 3963] and describes detailed operations for network/node mobility support in the PMIPv6 domain.

-- draft-sijeon-mext-nemo-pmip6

Multipath RTP

The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints.

-- draft-singh-avt-mprtp

PLMT

The single path transport provided by the Transmission Control Protocol (TCP) can be extended to a multipath transport session for multi-homed end hosts by coupling several TCP connections over multiple interfaces of the end hosts. Payload Multi-connection Transport (PLMT) is a multipath protocol variant that encodes all the control/signaling information in the payload of TCP connections and therefore requires no additional TCP options. PLMT allows for the simultaneous use of the multiple connections over potentially disjoint paths while being mostly backward compatible to single path transport of TCP. PLMT operates as an additional protocol layer between the network stack and the application layer. This document describes PLMT as an example for a multipath mechanism that could possibly be realized entirely in the user-space of an operating system.

-- draft-singh-mptcp-plmt

SIP APIs for Communications on the Web

This memo describes a standards based approach to enable web based interactive multimedia communications. The objective is giving web developers the software tools to add communication widgets to web pages. The proposed SIP API does not necessarily require SIP protocol expertise by web developers for basic multimedia communications though it can be extended to port complex VoIP services to the web. The SIP API can also support the transition from network infrastructure based VoIP to rich web based communications. The benefits of the formal REST architecture of the web are extended to real time communications. Only two standard application layer protocols are required: HTTP for signaling data communications such as in SIP and/or XMPP and UDP for real time media transport. We consider replacing SDP with metadata about media, displays and user controls. RTP data functionality can also be moved to the application itself. NAT traversal and other functions are delegated to HIP.

-- draft-sinnreich-sip-web-apis

Logging of NAT Events

Carrier grade NAT (CGN) devices are required to log events like creation and deletion of translations and information about the resources it is managing. The logs are required in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices behave differently and hence it is difficult to expect a consistent behavior. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices.

-- draft-sivakumar-behave-nat-logging

DLEP

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary.

-- draft-sratliff-dlep

DLEP

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary.

-- draft-sratliff-manet-dlep

tictoc-mpls

The TICTOC charter specifies that the working group is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). We discuss here issues specific to MPLS PSNs.

-- draft-stein-tictoc-mpls

Route Configuration by DHCPv6

Currently, more and more hosts have multiple interfaces such as GPRS, WiFi etc. One key issue is how to make the applications on the host access the network accordingly through the proper interfaces. The approach presented in this document is to define new DHCPv6 option to configure route tables of the hosts. In this way, the hosts can select a appropriate route.

-- draft-sun-mif-route-config-dhcp6

Considerations for Stateless Translation

With the approaching exhaustion of IPv4 address space, large-scale SPs are now faced with the only real option to deploy IPv6 in a timely manner. In order to achieve smooth transition to IPv6, migration tools should be introduced for different deployment models. Among different IPv6 transition mechanisms, dIVI is a prefix-specific and stateless address mapping method which can directly translate IPv4 packet to IPv6 packet. This document describes the challenges and requirements for large SP to deploy IPv6 in operational network, the experimental results of dIVI in our laboratory and the considerations for dIVI deployment in large SP operational network.

-- draft-sunq-v6ops-ivi-sp

Labelcast Protocol

This document presents a light-weight, point-to-multipoint transport layer protocol named Labelcast, which utilizes a fix-length transport layer label to forward multicast packets. Labelcast is not a universal solution for Internet multicast, but aims to give an efficient point-to-multipoint data distribution protocol deployed in medium or small scale edge networks. Since Labelcast provides rich functions of quality monitoring, it's suitable to be applied in streaming data distribution systems.

-- draft-sunzhigang-sam-labelcast

Apex-CNAME

This document proposes a modification to CNAME record to coexist with SOA and NS records at the zone apex. This proposal will improve aliasing in the DNS system. The users are often forced to manually add duplicate A, AAAA and MX records by copying data from the target zone to the aliased zone. This forces zone owner to keep track of target domain name since the mismatch in the data could cause failures. This administrative burden will be eliminated by allowing CNAME to coexist with NS and SOA resource records.

-- draft-sury-dnsext-cname-at-apex

Stateful PCE

A PCE can be either stateful or stateless. The information carried in stateful PCE are more detailed than that of stateless PCE. With the state capability of PCEs, the PCCs may make advanced and informed choices about the PCEs to use. This draft focus on stateful PCE, describes the applicability of stateful PCE and gives the IGP and PCEP extensions to support stateful PCE.

-- draft-tang-pce-stateful-pce

SEAL

For the purpose of this document, a subnetwork is defined as a virtual topology configured over a connected IP network routing region and bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.

-- draft-templin-intarea-seal

VET

Enterprise networks connect hosts and routers over various link types, and often also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.

-- draft-templin-intarea-vet

IRON

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth through Provider Independent addressing while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group.

-- draft-templin-iron

Provider-Managed IRON

The Internet Routing Overlay Network (IRON) is a new internetworking architecture based on encapsulation of inner network layer packets within outer network layer headers using a non-broadcast, multiple access (NBMA) virtual interface model. IRON suggests a third-party global deployment of servers and relays to achieve a Provider- Independent (PI) routing and addressing framework, but there may be instances in which an Internet Service Provider (ISP) wishes to manage its own IRON deployment. This document presents a Provider- Managed IRON framework that offers a fast path alternative for deployment of a long term solution.

-- draft-templin-iron-pm

Teredo Extensions

This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs), and support for more efficient communication.

-- draft-thaler-v6ops-teredo-extensions

LIS Discovery by IP

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

-- draft-thomson-geopriv-res-gw-lis-discovery

6LoWPAN Backbone Router

Some LLN subnets are expected to scale up to the thousands of nodes and hundreds of routers. This paper proposes an IPv6 version of the Backbone Router concept that enables such a degree of scalability using a high speed network as a backbone to the subnet.

-- draft-thubert-6lowpan-backbone-router

RRH

For new classes of devices such as highly constrained nodes, forward and return Record Route capabilities are required to enable basic forwarding operations. This memo defines a such a technique for IPv6.

-- draft-thubert-6man-reverse-routing-header

RA Suppression

We propose to strongly reduce the usage of Neighbor Discovery in WSN by ignoring the global IPv6 prefix inside the WSN. The IPv6 prefix will be added (resp. removed) by the Border Router during the header decompression (resp. compression). This proposal has three main advantages: (i) reduce the number of exchanges inside the WSN, (ii) reduce the time needed by a sensor node to join the WSN (this is important when sensors are moving inside the WSN) and finally (iii) simplify multi-homing management. This document also studies the impact of this proposal on different architectures (star, mesh, route over) with LOWPAN_IPHC Encoding Format.

-- draft-toutain-6lowpan-ra-suppression

IPFIX IE-DOCTORS

This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas.

-- draft-trammell-ipfix-ie-doctors

IPFIX IEspec

This document describes a lightweight textual format for describing IPFIX Information Models, IPFIX Templates, and IPFIX Options Templates, designed for easy human readability and writability, and fast, easily implemented and deployed parsing and generation.

-- draft-trammell-ipfix-text-iespec

PT66-AC

This document describes a method to extend IPv6 prefix translation [NAT66] to statelessly translate between IPv6 prefixes of differing lengths. This technique, called PT66 addressing bit compression (PT66-AC), provides a way to map a shorter prefix (such as the fixed [6to4] prefix) to a longer global unicast prefix, while avoiding stateful translation. The difference between the prefix lengths is compensated for by removing an unused string of subnetting bits, as specified, from the addresses within the shorter prefix.

-- draft-tremblay-pt66ac

Flow mobility support in PMIPv6

To support flow mobility in PMIPv6, the Mobile Node's Home Network Prefix should be able to be shared across its attachments and the network should support flow-based routing. This document specifies how to extend PMIPv6 to meet these requirements.

-- draft-trung-netext-flow-mobility-support

Flow tracking procedure for PMIPv6

A mobile node (MN) can connect to the network by using multiple interfaces simultaneously or sequentially. The quality of each connection can be changed due to many reasons such as the movement of the MN and the interference from the network. To guarantee the quality of service, some flows can be moved from a bad connection to another better one. In this draft we discuss about how to extend the Proxy Mobile IPv6 (PMIPv6) to support such kind of flow mobility.

-- draft-trung-netext-flow-tracking

NATx4 Log Reduction

Various IPv6 transition strategies require the introduction of large -scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

-- draft-tsou-behave-natx4-log-reduction

Discover a Real China in IETF 79

This document provides an introduction to your hosts in Beijing and to some of the sights of China.

-- draft-tsou-ietf79-discover-china

Configuring Large-Scale IP Networks

This memo discusses the steps required to bring network devices in a service provider network into service in an automated fashion. The memo identifies known solutions where they exist, but notes some gaps that require further specification.

-- draft-tsou-opsawg-network-configuration

"Gateway-Initiated" 6rd

This document proposes an alternative 6rd deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned gateway collocated with the operator's IPv4 network edge, rather than from customer equipment. The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment, as well as smaller IPv4 routing tables.

-- draft-tsou-softwire-gwinit-6rd

Mobile Operator Transition

This document provides a transition guide for a large-scale mobile network operator migrating its network from IPv4 to IPv6.

-- draft-tsou-v6ops-mobile-transition-guide

MD4 to Historic

This document recommends the retirement of MD4 and discusses the reasons for doing so. This document recommends RFC 1320 be moved to Historic status.

-- draft-turner-md4-to-historic

Name Based API

Today, networked applications typically make use of name-oriented network abstractions. There is a myriad of application development frameworks who provide abstracted APIs allowing applications to refer to their peers by name. These abstractions normally only provide application-layer protocol functionality. They are normally uni- lateral solutions, the support for the protocol used is implied by the service accessed on the remote peer(s). We suggest a unified API for networked applications. Isomorphic to the existing name-based solutions, but with added network-related functionality. Providing an existing application-layer protocols with network features such as mobility, multi-homing, IPv4/IPv6 interoperability, NAT-traversal and so on...

-- draft-ubillos-name-based-api

Name-Based Sockets Architecture

This memo defines Name-based sockets. name-based sockets allow application developers to refer to remote hosts (and it self) by name only, passing on all IP (locator) management to the operating system. Applications are thus relieved of re-implementing features such as multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and address management in general. The operating system can in turn re- use the same solutions for a whole set of guest applications. name- based sockets aims to provide a whole set of features without adding new indirection layers, new delays or other dependences while maintaining transparent backwards compatibility.

-- draft-ubillos-name-based-sockets

DCP Transport

(This document is a description of the decentralized viechle to viechle probe mechanism currently being prototyped. The main purpose of disclosing this -00 document is to introduce the application idea and start discussion within the DTNRG. Because of this, the current mechanism described in this docment does not conform to the protocols defined in the DTNRG at this moment. The mechanism should be updated based on the discussion in this group.) This document describes the transport protocol specification used for the decentralized probe system for vehicles. The probe system exchanges probe messages between vehicles using a wireless communication methods with low bandwidth and lossy properties. The communication environment dynamically changes as vehicle moves. The protocol try to utilize the limited bandwidth as much as possible and increase reachability rate by using sender-side error correction mechanism.

-- draft-uehara-dtnrg-decentralized-probe-transport

IPv6 Multihoming without NAT

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria .

-- draft-v6ops-multihoming-without-nat66

Multi-MTU Subnets

In the early days of the internet, many different link types with many different maximum packet sizes were in use. For point-to-point or point-to-multipoint links, there are still some other link types (PPP, ATM, Packet over SONET), but multipoint subnets are now almost exclusively implemented as ethernets. Even though the relevant standards mandate a 1500 byte maximum packet size for ethernet, more and more ethernet equipment is capable of handling packets bigger than 1500 bytes. However, since this capability isn't standardized, it is seldom used today, despite the potential performance benefits of using larger packets. This document specifies mechanisms to negotiate per-neighbor maximum packet sizes so that nodes on a multipoint subnet may use the maximum mutually supported packet size between them without being limited by nodes with smaller maximum sizes on the same subnet.

-- draft-van-beijnum-multi-mtu

CoAP Utilization for Building Control

This draft describes an example use of the RESTful CoAP protocol for building automation and control (BAC) applications such as HVAC and lighting. A few basic design assumptions are stated first, then URI structure is utilized to define group as well as unicast scope for RESTful operations. RFC 3986 defines the URI components as (1) a scheme, (2) an authority, used here to locate the building, area, or node under control, (3) a path, used here to locate the resource under control, and (4) a query part (fragments are not supported in CoAP.) Next, it is shown that DNS can be used to locate URIs on the scale necessary in large commercial BAC deployments. Finally, a method is proposed for mapping URIs onto legacy BAC resources, e.g., to facilitate application-layer gateways. This proposal supports the view that (1) building control is likely to move in steps toward all-IP control networks based on the legacy efforts provided by DALI, LON, BACnet, ZigBee, and other standards, and (2) service discovery is complimentary to resource discovery and facilitates control network scaling.

-- draft-vanderstok-core-bc

Non-Managed Tunnels are Harmful

IPv6 is ongoing and natively being deployed by a growing community and it is important that the quality perception and traffic flows are as optimal as possible. Ideally it would be as good as the IPv4 perceptive experience. This paper looks into a set of transitional technologies where the actual user has IPv6 connectivity through the means of IPv6-in-IPv4 tunnels. A subset of the available tunnels has the property of being non-managed (i.e. 6to4 [RFC3056] and Teredo [RFC4380] ). While native IPv6 deployments will keep growing it is uncertain or even expected that non-managed IPv6 tunnels will be providing the same user experience and operational quality as managed tunnels or native IPv6 connectivity. This paper will detail some considerations around non-managed tunnels and will document the harmful element of these for the future growth of networks and the Internet.

-- draft-vandevelde-v6ops-harmful-tunnels

Network signaling for protocol selection

Within an administrative realm, especially during an IPv6 implementation period, the network operator has interest to have control on the IP protocol version (IPv4 or IPv6) used by the end systems and network devices. This document provides a problem statement about both protocol preference and protocol selection many network operators face when implementing IPv6 in a controlled process.

-- draft-vandevelde-v6ops-pref-ps

IPv6 MLPPP ID

This document specifies a new multi link protocol address class identifier. This new class will be able to contain an ipv6 address.

-- draft-vautrin-6man-ipv6-mlppp-id

IPv6 MLPPP ID

This document specifies a new multi link protocol address class identifier. This new class will be able to contain an ipv6 address.

-- draft-vautrin-pppext-ipv6-mlppp-id

4rd (IPv4 Rapid Deployment)

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv4 to end users via an IPv6 network infrastructure. This document aims at giving an alternative to family translation to operate an Ipv6-only network.

-- draft-vautrin-softwire-4rd

Suppressing connectivity checks in ICE

Connectivity checks as proposed by Interactive Connectivity Establishment (ICE) are used to detect problems that cause endpoints not to receive media. However, in some cases connectivity checks are not seen as necessary, or such checks are not feasible for certain bearer types. This document defines a new candidate address type for which connectivity checks are not performed.

-- draft-veikkolainen-mmusic-ice-suppress-checks

Multicast Addresses for Documentation

This document discusses which multicast addresses should be used for documentation purposes and reserves IPv6 multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes by deriving them from AS numbers and unicast addresses that are reserved for such purposes.

-- draft-venaas-mboned-mcaddrdoc

MPLS-TP and MPLS Multipath

Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over current high bandwidth multipath implementations. The tradeoffs involved in using multipath techniques with MPLS and MPLS-TP are described. Requirements are discussed which enable full MPLS-TP compliant LSP including full OAM capability to be carried over MPLS LSP which are traversing multipath links. Other means of supporting MPLS-TP coexisting with MPLS and multipath are discussed.

-- draft-villamizar-mpls-tp-multipath

Future Work for MultiMob WG

The WG MultiMob aims at defining a basic mobile multicast solution leveraging on network localized mobility management, i.e. Proxy Mobile IPv6 protocol. The solution would be basically based on multicast group management, i.e. IGMP/MLD, proxying at the access gateway. If such a basic solution is essential from an operational point of view, challenges with efficient resource utilization and user perceived service quality still persist. These issues may prevent large scale deployments of mobile multicast applications. This document attempts to identify topics for near future extension of work such as modifying multimob base solution, PMIPv6 and MLD/ IGMP for optimal multicast support, and adaptation of Handover optimization. Far future items such as extending to and modifying of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of multiple flows and multihoming will be dealt with in a future version.

-- draft-von-hugo-multimob-future-work

Common Mcast API

Group communication services exist in a large variety of flavors, and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to using a stable, upper layer protocol controlled by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, it describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet.

-- draft-waehlisch-sam-common-api

XCCDF Version 1.1.4

This document specifies the data model and Extensible Markup Language (XML) representation for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4. An XCCDF document is a structured collection of security configuration rules for some set of target systems. The XCCDF specification is designed to support information interchange, document generation, organizational and situational tailoring, automated compliance testing, and compliance scoring. The specification also defines a data model and format for storing results of security guidance or checklist compliance testing. The intent of XCCDF is to provide a uniform foundation for expression of security checklists and other configuration guidance, and thereby foster more widespread application of good security practices.

-- draft-waltermire-scap-xccdf

[STANDBY] has discussed how to achieve load-balancing among a group of NAT64 devices. However, it doesn't explore the issues with achieving load-balancing with load-balancers. In this memo, we propose our investigation on this topic. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119].

-- draft-wang-behave-nat64-load-balancer

IPv6 CE router Advanced requirements

This document continues the work undertaken by the IPv6 CE Router Phase I work in the IETF v6ops Working Group. Advanced requirements or Phase II work is covered in this document.

-- draft-wbeebee-v6ops-ipv6-cpe-router-bis

RP SA

This document analyzes the security associations used by current routing protocols, including RIPv2, OSPFv2, ISIS, BFD, and BGP. It also discusses the possible methods for the diversity issue of routing protocol security association (SA).

-- draft-wei-karp-analysis-rp-sa

IPv4-prefix-for-IPv6-Transition

This document specifies the use of a reserved IANA IPv4 address allocation to support the deployment of IPv6 transition technologies and IPv4 address sharing technologies post IPv4 exhaustion. Service providers are in the process of implementing IPv6 support by providing dual-stack IPv4 and IPv6 services to their end-users. One method for continued support of the IPv4 Internet post IANA IPv4 depletion is through the use of a carrier-provided NAT444 infrastructure. Another mechanism used to transition to IPv6 is an IPv6-in-IPv4 tunnel such as IPv6 Rapid Deployment (6RD). This document details the use of an IANA reserved address block for these purposes.

-- draft-weil-opsawg-provider-address-space

Shared Transition Space Request

This document requests a reserved IANA IPv4 address allocation as Shared Transition Space to support the deployment of IPv4 address sharing technologies post IPv4 exhaustion.

-- draft-weil-shared-transition-space-request

Nested compression

The appearance of wireless technologies in cellular network attracts the attentions to compress at least two layers of nested compression headers. This document describes a nested compression scenario, by coordinating the header fields that have similar functions or even are repeated in layers of nested compressed packet, to reduce processing latency, packet header payload and increase the compression efficiency.

-- draft-wei-tsvwg-nested-header-compression

Ivip ETR Address Forwarding

ETR Address Forwarding (EAF) is a novel method by which an IPv4 Core- Edge Separation solution to the Internet's routing scaling problem can tunnel packets from an ITR to an ETR. EAF involves using 31 bits of the IPv4 header for new purposes: bit 48, the More Fragments flag, the Fragment Offset field and the Header Checksum field - to carry a 30 bit ETR address. Consequently, packets in this format need to be handled by routers with upgraded functionality. EAF is an alternative to encapsulation and has advantages including: simpler ITRs and ETRs, direct support for conventional RFC 1191 PMTUD, no encapsulation overhead and full compatibility with IPsec AH and Traceroute. This I-D also briefly explores an alternative to this approach: a new header, of the same length and different, with a different 4 bit Version, to carry 31 bits of ETR address.

-- draft-whittle-ivip-etr-addr-forw

Mobility Considerations for 6LoWPAN

There has been discussion recently within the 6LoWPAN community regarding mobile usage scenarios. Mobility considerations is required for the deployment of SmartGrids. The mobility analysis for SmartGrid and 6lowpan deployment is required to ensure proper performance for the mobile usage cases. Also, mobility in 6LoWPAN sensor networks may present unique challenges to the 6LoWPAN architecture. Hence it is best to have mobility as a consideration upfront rather than an after thought in the development of 6LoWPAN milestones. This document provides a mobility perspective to the 6LoWPAN sensor network architecture.

-- draft-williams-6lowpan-mob

Connection Identity via TCP option

When an IP address is shared among several subscribers, it is impossible to determine which subscriber has initiated that TCP connection. This memo describes a technique to share the identity of a subscriber that initiated a TCP connection with the TCP server. The proposed method avoids altering the application-level payload and works well with SSL-protected connections. It uses a new TCP option for this purpose.

-- draft-wing-nat-reveal-option

PCP Design Considerations

This document summarizes changes from NAT-PMP to support the needs of a large-scale NAT and support IPv6. This document is for discussion purposes. It is not intended to be published as an RFC.

-- draft-wing-pcp-design-considerations

Happy Eyeballs SCTP

This document describes how to seamlessly migrate HTTP from running over TCP to running over SCTP, without negative impact to the user experience.

-- draft-wing-tsvwg-happy-eyeballs-sctp

Happy Eyeballs Dual Stack

This document describes how a dual-stack client can determine the functioning path to a dual-stack server. This provides a seemless user experience during initial deployment of dual-stack networks and during outages of IPv4 or outages of IPv6.

-- draft-wing-v6ops-happy-eyeballs-ipv6

HTTP for DTN delivery

This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks, by making every transit node in the network HTTP-capable, and doing peer HTTP transfers between nodes to move data hop-by-hop or subnet-by-subnet towards its final destination. HTTP is well- known and straightforward to implement in these networks.

-- draft-wood-dtnrg-http-dtn-delivery

Saratoga

This document specifies the Saratoga transfer protocol. Saratoga was originally developed to efficiently transfer remote-sensing imagery from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks.

-- draft-wood-tsvwg-saratoga

WSN convergence framework

This Internet Draft provides a detailed description of the convergence framework of Internet and WSN so far, including 4 main solutions and 2 additional technologies. The main aim of this document is to serve as a general reference for the convergence solution space, to take advantage of the two networks the advantages of diversity and meet the needs of network users. Furthermore, each solution is analyzed based on a number of evaluation considerations.

-- draft-wu-convergence-internet-wsn

ERP

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.

-- draft-wu-hokey-rfc5296bis

Tuning IGMPv3/MLDv2 Protocol Behavior

This document proposes a variety of optimization approaches for tuning IGMPv3 and MLDv2 protocols. It aims to provide useful guideline to allow efficient multicast communication in wireless and mobile networks using the current IGMP/MLD protocols.

-- draft-wu-multimob-igmp-mld-tuning

HA Initiated Flow Binding for Mobile IPv6

There are scenarios in which home agent initiated flow binding operations towards the mobile node is needed such as revoking a flow binding or moving a flow from one interface to another because of network resource availability. This document defines one new Mobility Header, two messages, several actions and two new sub- options to perform home agent initiated interactions for flow bindings in a mobile node. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes.

-- draft-xia-mext-ha-init-flow-binding

DHCPv4 Options for DSMIPv6

This document defines DHCPv4 options for dynamic discovery of home network information in Dual Stack Mobile IPv6. New DHCPv4 options are defined which allow a mobile node to request the home agent IPv4/v6 address, FQDN, or home network prefix and obtain it via the DHCPv4 response.

-- draft-xia-mext-hioptv4

Flow Binding in PMIPv6

This document introduces extensions to Proxy Mobile IPv6 that allows networks dynamically binding IP flows to different interfaces of a mobile node. Mobile Access Gateways can move flows to other mobile access gateways by establishing flow bindings at the local mobility anchor. Local mobility anchor sends packets from the offloaded flow seamlessly to the new mobile access gateway.

-- draft-xia-netext-flow-binding

DNS46 for Stateless Translator

The stateless translator can support IPv6-initiated communications as well as IPv4-initiated communications for IPv6 hosts using IPv4- translatable addresses. DNS support for the IPv6-initiated communication is defined in the DNS64 specification. This document defines the DNS46 function for the stateless translator.

-- draft-xli-behave-dns46-for-stateless

Source Address Mapping for ICMPv6

For stateless IPv4/IPv6 translator, it may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. This document defines a stateless address mapping mechanism for source address translation in ICMPv6 headers for such cases.

-- draft-xli-behave-icmp-address

CERNET IVI Translation Design

This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators, the communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in CERNET as a reference for the IETF standard documents on IPv4/IPv6 translation.

-- draft-xli-behave-ivi

NAT State Synchronization Using SCSP

To support NAT redundancy in hot standby mode [NAT-STANDBY] among a group of NAT devices, the dynamic NAT entries created at the primary NAT device should be synchronized consistently to the backup NAT device. This document describes a method of using the Server Cache Synchronization Protocol (SCSP) for NAT state synchronization and specifies the corresponding NAT specific components for this method.

-- draft-xu-behave-nat-state-sync

Redundancy for NAT Requirements

This document defines a set of requirements and a framework for ensuring redundancy for stateful Network Address Translators (NAT), including NAT44, NAT64 and NAT46.

-- draft-xu-behave-stateful-nat-standby

Hierarchical HIP

This document explores the benefits brought by extending the Host Identity Protocol (HIP) with hierarchical information. In addition, three types of candidate solutions are introduced.

-- draft-xu-hip-hierarchical

IPv6 RA Option for Stateless DHCP Server

This document proposes a new Router Advertisement option which allows IPv6 hosts to obtain the addresses of stateless DHCP servers. Thus, IPv6 hosts can directly contact stateless DHCP servers using unicast.

-- draft-xu-ipv6-ra-dhcp-server-option

NBS: Shim6

This document describes and defines shim6 as a mobility solution for name-based sockets. Using names rather than pseudo IP addresses, shim6 can handle a more diverse set of mobility scenarios. These changes allow a shim6 session to persist even through cases where one node has no working locators to its correspondent node. If the name is also a resolvable fully qualified domain name, the connection can be kept alive even if neither node have a working locator to the corresponding node. As can be the case if both nodes are mobile simultaneously.

-- draft-xu-name-shim6

Routing Architecture

IRTF Routing Research Group (RRG) is exploring a new routing and addressing architecture to address the issues with the current Internet, e.g., mobility, multi-homing, traffic engineering, and especially the routing scalability issue. This document describes a new identifier (ID)/locator split based routing and addressing architecture, called Routing Architecture for the Next Generation Internet (RANGI), in an attempt to deal with the above problems.

-- draft-xu-rangi

softwire mcast framework

The Internet will need to support IPv4 and IPv6 packets. Both address families and their attendent protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution for supporting E-IP unicast and multicast across an I-IP backbone. This document describes the mechanisms for suppporting Internet -style multicast across a set of E-IP and I-IP networks supporting softwires mesh.

-- draft-xu-softwire-mesh-multicast

Simple Tunnel Endpoint Signaling in BGP

The Softwire Mesh Framework provides a solution for intra-Autonomous System (AS) softwire, but not inter-AS softwire. The ability to provide inter-AS softwire extends the benefits of softwire to a larger scale. Indeed, the above Framework discusses the possibility of inter-AS softwire, but does not provide a solution. This document defines a specific BGP Extended Community attribute called the Tunnel Endpoint attribute, which allows for inter-AS softwire.

-- draft-xu-softwire-tunnel-endpoint

IPsec security for synchronzation

Cellular networks often use Internet standard technologies to handle synchronization. This document analyses the need for security methods for synchronization messages distributed over the Internet. This document also gives a solution on how to mark the synchronization message when IPSec is implemented in end to end frequency synchronization."

-- draft-xu-tictoc-ipsec-security-for-synchronization

Virtual Subnet

This document proposes a scalable data center network architecture which, as an alternative to the Spanning Tree Protocol Bridge network, uses a Layer 3 routing infrastructure based on BGP/MPLS IP VPN technology [RFC4364] with some extensions, together with some other proven technologies including ARP proxy [RFC925][RFC1027] to provide scalable virtual Layer 2 network connectivity services.

-- draft-xu-virtual-subnet

TESF Based on True IPv6 Address Access

The current Email infrastructure has the property that any host sending mail to the mail system can identify itself as any user name it wants. Furthermore, the current Email framework neither authenticates the sender nor traces the source of the mail, so even find a spam, the method is just to reject the mail or insert the mail source into "blacklist", and both of these methods can!_t deracinate the generation of spam. This document design a Email source address authentication based on true IPv6 address access to identify and authenticate the mail source address, to trace the mail sender effectively, and to deracinate the generation of spam.

-- draft-xwwang-ipv6-tesf

Hiding Transit-only Networks in OSPF

A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in LSAs but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and minimize remote attack vulnerability.

-- draft-yang-ospf-hiding

Broadband Network Transition

This document discusses about different IPv6 migrating solutions for each part of the Large-scale broadband network with layer 2 access infrastructure. They are based on the requirements of providing existing broadband services in v4v6-coexisting or IPv6-only scenarios. The document provides analysis of different solutions and also describes the suitable scenarios that each solution may be deployed in.

-- draft-yang-v6ops-v4v6tran-bb-transition-guide

This document defines VC-ID-ASM, a virtual channel based inter- domain any source multicast protocol. Based on extended source specific multicast, the participants join a virtual channel and a shared tree is formed. The receivers receive the multicast traffic along the shared tree, sense the source addresses and then initiate the switch process from the shared tree to the source trees.

-- draft-ychen-vc-id-asm

PANA with IPv4 Unspecified Address

This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address.

-- draft-yegin-pana-unspecified-addr

DHCPv6 Prefix Pool Option

The Prefix Pool option provides an automatic mechanism for the messages exchange between DHCPv6 server and DHCPv6 Relay Agent. The information about Prefix Pools maintained on DHCPv6 server can be transferred from server to relay agent through this DHCPv6 option to support the necessary route aggregation on the provide edge router, which has a huge number of routes pointing to the customer networks before.

-- draft-yeh-dhc-dhcpv6-prefix-pool-opt

EUDP Specification

This document is a specification of Extendable User Datagram Protocol (EUDP), which is based on User Datagram Protocol (UDP), but allows to extend the header using options.

-- draft-yevstifeyev-eudp

HCITP

This document is a specification of Hardware Information Configuration Transfer Protocol. This protocol is used to request and transfer information about hardware.

-- draft-yevstifeyev-hcitp

A+P Addressing Extension

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 the depletion 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 proposes an IPv4 address sharing scheme, 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 single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional end point identifiers, thus leaving a reduced range of ports available to applications. 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.

-- draft-ymbk-aplusp

The RPKI/Router Protocol

In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh.

-- draft-ymbk-rpki-rtr-protocol

Service Mobility for Virtualized Networks

Network virtualization technique leveraged by a virtual machine makes it possible to dynamically relocate functional entities without topological and physical constraints. By tapping into this technique, service mobility, which deals with not only functional entities but also sessions established between those entities, will become possible and such capability is especially longed for realizing more scalable and reliable telecom networks. This document provides the reference model for service mobility in a virtual environment and defines the control protocol between the virtualized platform and the managing controller to realize service mobility.

-- draft-yokota-cloud-service-mobility

dmm-scenario

This document explores applicability of Distributed Mobility Management (DMM) and use case scenarios for different parts of the mobile network. DMM approaches and scenarios are divided into two cases: partially and fully distributed. For each case, benefits and issues are provided. It also refers to applicability of existing protocols and necessity of development of new protocols in order to provide a guideline for best suited solutions for the target architecture.

-- draft-yokota-dmm-scenario

Large Flow Classification

Network traffic has shown the combination of few very high bit rate flows (large flow) and huge amount of very low bit flows (small flow), which causes uneven load balance over ECMP paths. Differentiating large flow and small flow packets in IP/MPLS networks enables enhanced ECMP transport. Enhanced ECMP applies different distribution methods to large flow packets and small flow packets to improve the load balance. The classification also enables an effective congestion control. This draft proposes large flow classification in IPv6 protocol for this purpose.

-- draft-yong-6man-large-flow-classification

LFC-FAT

Network traffic has shown the combination of few very high bit rate flows (large flow) and a huge amount of very low bit rate flows (small flow), which causes uneven load balance over ECMP or LAG. Differentiating large flow and small flow packets in IP/MPLS networks enables an enhanced ECMP transport. Enhanced ECMP applies different distribution methods to large flow packets and small flow packets to improve the load balance and congestion control. This draft proposes large flow classification scheme for flow awareness transport in PSN.

-- draft-yong-pwe3-lfc-fat-pw

Revealing the hosts behind NAPT

When an IP address is shared among several subscribers, it is impossible to determine which subscriber has initiated that TCP connection. This memo describes a technique to share the identity of a subscriber that initiated a TCP connection with the TCP server.. The proposed method avoids altering the application-level payload and works well with SSL-protected connections.

-- draft-yourtchenko-nat-reveal-hash

HIP Failure Detection and Recovery

Fault tolerance is one of greatest feature of multihomed host. This document proposes a failure detection and communication recovery mechanism for Host Identity Protocol. It can be applied to HIP by using new defined HIP parameters. A HIP-enabled multihomed host can switch to alternative locator if current link breaks down by adopting this mechanism.

-- draft-yuan-hiprg-failure-detection-recovery

One-time Address-Prefix Based ORF

This document defines a new Outbound Router Filter (ORF) type for BGP, termed "One-time Address Prefix Outbound Route Filter", which would allow a BGP speaker to send to its BGP peer a route refresh request with a set of address-prefix-based filters to make the peer re-advertise only the specific routes matching the filters to the speaker. This ORF-type enables a BGP speaker to recover some specific "problematic" routes without requiring its peer to re- advertise the whole Adj-RIB-Out of specific address family, which makes the trouble shooting operation (such as packets tracking) more efficient and reduces the impact on network stability. This filter does not change the outbound route filters on BGP peers and should only be used for one-time filtering.

-- draft-zeng-one-time-prefix-orf

NAT64 Load Balancing

This document investigates several load-balancing approaches for NAT64 devices and analyses the advantages and disadvantages of various prefix selection policies. Both stateless and stateful NAT64 schemes are considered in this document.

-- draft-zhang-behave-nat64-load-balancing

This specification describes the requirements of Tandem Connection Monitoring (TCM) configuration via GMPLS control plane in MPLS-TP network and provides the procedure of creating TCM path segment tunnel on a transport path to meet the requirements of TCM configuration.

-- draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config

An Extension of HIP Base Exchange

In this document, we propose an extension of HIP Base Exchange (BEX) which facilitates HIP hosts to protect their identity privacy. Apart from describing the protocol and packet formats, we also attempt to analyze the applicability and the security strength of the proposed approach. This work is based on BLIND [YLI04].

-- draft-zhang-hip-privacy-protection

Redundancy for IPsec D-Deployment

This informational document attempts to analyze several critical issues with failover of IPSec Gateways (IG) distributed across different networks. Additionally, several candidate approaches to such issues are listed and compared. The objective of this work is to provide useful information for the future research in the failover of multiple geographically distributed IGs.

-- draft-zhang-ipsecme-distributed-redundancy

RSVP-TE Extensions of Associated LSP

This document provides a method to bind two unidirectional LSPs into an associated bidirectional LSP, by extending the Extended ASSOCIATION object defined in [I-D.berger-ccamp-assoc-info].

-- draft-zhang-mpls-tp-rsvpte-ext-associated-lsp

Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable [1]. Although the issues of mobile multicast in the PMIPv6 network are being discussed in the Multimob WG, how to provide the service connectivity for the mobile multicast source is still a problem for the PMIPv6. This document discusses the extensions of the PMIPv6 to support the multicast source mobility.

-- draft-zhang-multimob-msm

October 2010

The hierachical Path Computation Element (PCE) architecture defined in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing hierarchical PCE procedures which are described in [PCE-HIERARCHY-FWK].

-- draft-zhang-pcep-hierarchy-extensions

LDP Multi Topology Extension

Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. Each route computed by OSPF or IS-IS is associated with a specific topology. Label Distribution Protocol (LDP) is used to distribute labels for FECs advertised by routing protocols. It is a natural requirement to extend LDP in order to make LDP be aware of MT and thus take advantage of MT based routing. This document describes options to extend the existing MPLS signalling protocol (LDP) for creating and maintaining Label Switching Paths (LSPs) in a Multi-Topology enviroment.

-- draft-zhao-mpls-ldp-multi-topology

RSVP-TE Multi Topology Extension

This document describes options to extend the existing MPLS signalling protocol RSVP for creating and maintaining Label Switching Paths (LSPs) in a Multi-Topology environments.

-- draft-zhao-mpls-rsvp-te-multi-topology

PCEP P2MP Procedures

The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. 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.

-- draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Host-initiated NAT

This document presents a new method to implement the NAT function, which requires the cooperating of the hosts and the NAT gateway. The proposed NAT mechanism is called Host-initiated NAT, or HI-NAT for short. Traditional NAT function is performed in the gateway, while the hosts are not aware of the address translation at all. One drawback of such mechanism is that all translation works need to be done in one device, the NAT gateway, which may bring performance bottleneck. The presented HI-NAT mechanism shows another possible solution to improve network performance by the cooperating of the hosts and the Gateway. In more details, the hosts will initiate the NAT procedure with its local IP address. After getting the translated IP address, the hosts will use it in every packet sending out to ease the translating workload of the NAT gateway.

-- draft-zheng-host-initiated-nat

October 2010

This document introduces a new Cryptographic Authentication TLV which is used in LDP Hello message as an optional parameter. It enhances the authentication mechanism for LDP by securing the Hello message against spoofing attack.

-- draft-zheng-mpls-ldp-hello-crypto-auth

Circuit Emulation Services over SCTP

This memo defines the mechanism for Time Division Multiplexing (TDM) transport over SCTP or Circuit Emulation Services over SCTP.

-- draft-zhiyfang-fecai-cesosctp

IVI xlate rules aware in BGP

This memo defines MP-BGP-4 to support IVI [1] to make IVI services aware in whole internet domain and trigger double IVI to save the ALG (Application Layer Gateway) resource , also use dIVI as a tunnel to provide full meshed softwire.

-- draft-zhiyfang-ivi-aware-bgp

DS-lite on Pt-to-Pt Access Network

Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a proposal to logically extend existing access tunnels beyond the access gateway to DS-Lite Address Family Transition Router element (AFTR) using softwires with an embedded context identifier. This memo describes a deployment model using GI-DS-lite in Point-to-Point access network.

-- draft-zhou-softwire-ds-lite-p2p

Mobile Use Case

This document describes an use case for migrating from IPv4 to IPv6 in a very large mobile network. Its purpose is to enhance general understanding of the challenges associated with the migration of such a network to IPv6 operation.

-- draft-zhou-v6ops-mobile-use-case

BTMM

This draft describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery and end- to-end connectivity in face of Network Address Translators (NAT) and mobility of devices.

-- draft-zhu-mobileme-doc

Mobility Survey

Over the last two decades many 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.

-- draft-zhu-mobility-survey

ZRTP

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. ZRTP secures media sessions which include a voice media stream, and can also secure media sessions which do not include voice by using an optional digital signature.

-- draft-zimmermann-avt-zrtp

TEAM

The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the Tunneled Extensible Authentication Method (TEAM), which provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP authentication mechanisms. TEAM uses TLS to protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy. TEAM also provides support for chaining multiple EAP mechanisms, cryptographic binding between authentications performed by inner EAP mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), and fragmentation and reassembly.

-- draft-zorn-emu-team

LIF Implementation Guidelines

A Logical Interface is a software module internal to the host that is available in all popular operating systems. The use of this Logical Interface allows supporting different network-based mobility management solutions. In the NETEXT WG, work has been carried out to define ways in which a Logical Interface can help IP flow mobility (IFOM) for Proxy Mobile IPv6 [I-D.draft-ietf-netext-logical- interface-support]. The same Logical Interface construct can help other mobility management solutions like 3GPP GPRS Tunnelling Protocol (GTP), and it can add benefits to multi-access scenarios such as 3GPP Multi Access PDN Connectivity (MAPCON). This document provides guidelines for the implementation and configuration of a generic Logical Interface.

-- draft-zuniga-mif-lif-implementation-guidelines

Multicast Services using PMIPv6

The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base- solution]. In this document, an enhancement is proposed to the base solution to use a dedicated multicast LMA as the topological anchor point for multicast traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement provides benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployments scenarios.

-- draft-zuniga-multimob-smspmip

JSON Schema Media Type

JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.

-- draft-zyp-json-schema

CATNIP

This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.

-- rfc1707.txt

Management of Internet Address Space

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. Possible modifications to the management practices are examined, and potential outcomes considered. Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted.

-- rfc1744.txt

Recommendation for IPng

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. This recommendation was accepted by the Internet Engineering Steering Group (IESG).

-- rfc1752.txt

IPATM WG ATM Forum Recommendations V1

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This RFC is issued for the benefit of community members. The information contained in this document is accurate as of the date of publication, but is subject to change. Subsequent RFCs will reflect such changes. The content of this memo was submitted by the IETF Liaison to the ATM Forum as contribution number 94-0954 in the ATM Forum's documentation process on 14 September 1994.

-- rfc1754.txt

June 1995

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo is for information purposes only and is not one of the IPv6 specifications. Distribution of this memo is unlimited.

-- rfc1809.txt

Report on MD5 Performance

MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6. When enabled, the MD5 algorithm operates over the entire data packet, including header. This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps. These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM. If MD5 cannot support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future. This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations.

-- rfc1810.txt

ESP DES-CBC

This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP).

-- rfc1829.txt

ESP 3DES

This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP).

-- rfc1851.txt

IPv6 Address Allocation Management

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.

-- rfc1881.txt

IPv6 Unicast Address Allocation Architecture December 1995

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan.

-- rfc1887.txt

Classical versus Transparent IP Proxies

Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.

-- rfc1919.txt

A Compact Representation of IPv6 Addresses

IPv6 addresses, being 128 bits long, need 32 characters to write in the general case, if standard hex representation, is used, plus more for any punctuation inserted (typically about another 7 characters, or 39 characters total). This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes.

-- rfc1924.txt

Native ATM Support for ST2+

As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS). The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.) Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component. This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: - ATM to internet, - internet to ATM, and - internet to internet across ATM.

-- rfc1946.txt

Path MTU Discovery for IPv6

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.

-- rfc1981.txt

Glossary

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.

-- rfc1983.txt

October 1996

IP unicast address allocation and management are essential operational functions for the Public Internet. The exact policies for IP unicast address allocation and management continue to be the subject of many discussions. Such discussions cannot be pursued in a vacuum - the participants must understand the technical issues and implications associated with various address allocation and management policies. The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. The major focus of this document is on two possible policies, "address ownership" and "address lending," and the technical implications of these policies for the Public Internet. For the organizations that could provide reachability to a sufficiently large fraction of the total destinations in the Internet, and could express such reachability through a single IP address prefix the document suggests to use the "address ownership" policy. However, applying the "address ownership" policy to every individual site or organization that connects to the Internet results in a non-scalable routing. Consequently, this document also recomments that the "address lending" policy should be formally added to the set of address allocation policies in the Public Internet. The document also recommends that organizations that do not provide a sufficient degree of routing information aggregation, but wish to obtain access to the Internet routing services should be strongly encouraged to use this policy to gain access to the services.

-- rfc2008.txt

GPS-Based Addressing and Routing

GPS-Based Addressing and Routing

-- rfc2009.txt

Multicast over UNI 3.0/3.1 based ATM

Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task. This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. ATM based IP hosts and routers use a Multicast Address Resolution Server (MARS) to support RFC 1112 style Level 2 IP multicast over the ATM Forum's UNI 3.0/3.1 point to multipoint connection service. Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group. The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints.

-- rfc2022.txt

Network Renumbering Overview

The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet Service Providers (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.

-- rfc2071.txt

Router Renumbering Guide

IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes in Internet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration. Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort. Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.

-- rfc2072.txt

RIPng for IPv6

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet. This specification represents the minimum change to the Routing Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723 [2], necessary for operation over IPv6 [3].

-- rfc2080.txt

RIP-2 Applicability

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This report is a prerequisite to advancing RIPng on the standards track.

-- rfc2081.txt

Toshiba's Router Extension for ATM

This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "Cell Switch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such as RSVP.

-- rfc2098.txt

IPv4 Address Behavior Today

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4.

-- rfc2101.txt

Nimrod Mobility Support

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol.

-- rfc2103.txt

Cisco's Tag Switching Architecture

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described.

-- rfc2105.txt

ISO Transport on top of TCP

This document is a revision to STD35, RFC1006 written by Marshall T. Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. The goal of this version is to minimise the number of changes to RFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users.

-- rfc2126.txt

FANP Specification

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By using FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is; (1) soft-state cut-through path (Dedicated-VC) management (2) protocol between neighbor nodes instead of end-to-end (3) applicable to any connection oriented datalink platform

-- rfc2129.txt

Internet & TCP/IP Tools & Utilities

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet.

-- rfc2151.txt

Service Location Protocol

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.

-- rfc2165.txt

APPN Implementer's Workshop

This document specifies - a set of extensions to RFC 1795 designed to improve the scalability of DLSw - clarifications to RFC 1795 in the light of the implementation experience to-date. It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology. This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSw RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.

-- rfc2166.txt

AREQUIPA

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS). Given a mapping from service classes, as defined by INTSERV[6], to ATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward. The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud. We discuss the implementation of Arequipa for hosts running IPv4 and IPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service. In particular we show how - Arequipa can be implemented in IPv4 by slightly modifying the - Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache, - Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses. Finally, we address safety and security implications.

-- rfc2170.txt

Routing Aspects Of IPv6 Transition

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document. The proposals contained in this document are based on the work of the Ngtrans working group.

-- rfc2185.txt

ICP

This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use. ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior.

-- rfc2187.txt

Site Security Handbook

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.

-- rfc2196.txt

RSVP

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.

-- rfc2205.txt

RSVP MIB using SMIv2

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu.

-- rfc2206.txt

RSVP Extensions for IPSEC

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6.

-- rfc2207.txt

Integrated Services MIB using SMIv2

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu.

-- rfc2213.txt

Network Element Service Template

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications).

-- rfc2216.txt

DNS Key Exchange Delegation Record

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. For example, a system seeking to use IP Security [RFC- 1825, RFC-1826, RFC-1827] to protect IP packets for a given destination can use this mechanism to determine the set of authorised remote key exchanger systems for that destination.

-- rfc2230.txt

Multihoming

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system.

-- rfc2260.txt

Using LDAP as a Network Information Service

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success.

-- rfc2307.txt

Internet Performance Recommendations

This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.

-- rfc2309.txt

Real Time Streaming Protocol

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).

-- rfc2326.txt

APPN/HPR in IP Networks

APPN/HPR in IP Networks

-- rfc2353.txt

Administratively Scoped IP Multicast

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to or the author.

-- rfc2365.txt

PF_KEY Key Management API

A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon).

-- rfc2367.txt

IPv6 Multicast Address Assignments

IPv6 Multicast Address Assignments

-- rfc2375.txt

RSVP over ATM Implementation Requirements

This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.

-- rfc2380.txt

Some Testing Tools for TCP Implementors

Some Testing Tools for TCP Implementors

-- rfc2398.txt

The OAKLEY Key Determination Protocol

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms.

-- rfc2412.txt

Multiprotocol over Frame Relay

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.

-- rfc2427.txt

FTP Extensions for IPv6 and NATs

The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.

-- rfc2428.txt

Proposed TLA and NLA Assignment Rules

Proposed TLA and NLA Assignment Rules

-- rfc2450.txt

IPv6 Specification

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.

-- rfc2460.txt

IPv6 Packets over Ethernet

IPv6 Packets over Ethernet

-- rfc2464.txt

IPv6 over FDDI

IPv6 over FDDI

-- rfc2467.txt

Canonical Ordering Of Link-Layer Addresses

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.

-- rfc2469.txt

IPv6 over Token Ring

IPv6 over Token Ring

-- rfc2470.txt

Generic Packet Tunneling in IPv6

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.

-- rfc2473.txt

Differentiated Services Field

Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of: - setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), - using those bits to determine how packets are forwarded by the nodes inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity. This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined. For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].

-- rfc2474.txt

Architecture for Differentiated Services

This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.

-- rfc2475.txt

IPv6 over NBMA networks

This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described. Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor Discovery protocol operation within Logical Links, and inter-router NHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported.

-- rfc2491.txt

IPv6 over ATM Networks

This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.

-- rfc2492.txt

IPv6 Datagrams on ARCnet

IPv6 Datagrams on ARCnet

-- rfc2497.txt

Limitations of Internet Protocol Suite

The Large-Scale Multicast Applications (LSMA) working group was chartered to produce documents aimed at a consensus based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements.

-- rfc2502.txt

Anti-Spam Recommendations

This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*). The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature. The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack. A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam.

-- rfc2505.txt

IP Header Compression

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.

-- rfc2507.txt

Compressing IP/UDP/RTP Headers

This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

-- rfc2508.txt

Reserved IPv6 Subnet Anycast Addresses

The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.

-- rfc2526.txt

Transmission of IPv6 Packets over IPv4

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet".

-- rfc2529.txt

BGP-4 Multiprotocol Extensions for IPv6 IDR

BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.

-- rfc2545.txt

TN3270E Using SMIv2 MIB

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods. It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data.

-- rfc2561.txt

DHCP Auto-Configuration Option

Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-local IP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own.

-- rfc2563.txt

FTP Security Considerations

The specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security. The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP.

-- rfc2577.txt

APPN/HPR in IP Networks MIB

APPN/HPR in IP Networks

-- rfc2584.txt

IPv6 over Frame Relay Networks

This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.

-- rfc2590.txt

Assured Forwarding PHB Group

This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.

-- rfc2597.txt

ILMI-Based Server Discovery for ATMARP

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers.

-- rfc2601.txt

ILMI-Based Server Discovery for MARS

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers.

-- rfc2602.txt

ILMI-Based Server Discovery for NHRP

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.

-- rfc2603.txt

The Internet and the Millennium Problem (Year 2000)

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation.

-- rfc2626.txt

NAT Terminology and Considerations

Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.

-- rfc2663.txt

Non-Terminal DNS Name Redirection

Non-Terminal DNS Name Redirection

-- rfc2672.txt

IPv6 Jumbograms

A "jumbogram" is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.

-- rfc2675.txt

QoS Routing Mechanisms and OSPF Extensions

This memo describes extensions to the OSPF [Moy98] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment of QoS routing capabilities with the minimum possible impact to the existing routing infrastructure. In addition, experience from an implementation of the proposed extensions in the GateD environment [Con], along with performance measurements is presented.

-- rfc2676.txt

Integrated Services over Low-bitrate Links September 1999

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of the Internet Multimedia Conferencing Architecture [1]; additional components required for application services such as Internet Telephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.

-- rfc2689.txt

A Single Rate Three Color Marker

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner [RFC2475, RFC2474]. The srTCM meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise.

-- rfc2697.txt

A Two Rate Three Color Marker

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner [RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks its packets based on two rates, Peak Information Rate (PIR) and Committed Information Rate (CIR), and their associated burst sizes to be either green, yellow, or red. A packet is marked red if it exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the CIR.

-- rfc2698.txt

Multicast Listener Discovery for IPv6

This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.

-- rfc2710.txt

IPv6 Router Alert Option

This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.

-- rfc2711.txt

Traffic Flow Measurement: Meter MIB

The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised.

-- rfc2720.txt

SRL: A Traffic Flow Language

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.

-- rfc2723.txt

RTFM: New Attributes

The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. Extensions described include Address Attributes such as DSCodePoint, SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters for Integrated Services are also discussed.

-- rfc2724.txt

Routing Policy System Security

The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.

-- rfc2725.txt

MADCAP

This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.

-- rfc2730.txt

RSVP Diagnostic Messages

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.

-- rfc2745.txt

RSVP Operation Over IP Tunnels

This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.

-- rfc2746.txt

RSVP Cryptographic Authentication

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.

-- rfc2747.txt

COPS

This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.

-- rfc2748.txt

Hyper Text Caching Protocol (HTCP/0.0)

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions.

-- rfc2756.txt

SLAPM-MIB

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data.

-- rfc2758.txt

Ongoing TCP Research Related to Satellites

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks.

-- rfc2760.txt

IP Based Virtual Private Networks

This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.

-- rfc2764.txt

SIIT

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts.

-- rfc2765.txt

Dual Stack Hosts using BIS

In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications.

-- rfc2767.txt

Abstract API for Multicast Address Allocation February 2000

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.

-- rfc2771.txt

6Bone Backbone Routing Guidelines

The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment. This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.

-- rfc2772.txt

Internet Transparency

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer. This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.

-- rfc2775.txt

MZAP

This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered.

-- rfc2776.txt

IANA Assignments

This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers.

-- rfc2780.txt

Generic Routing Encapsulation

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.

-- rfc2784.txt

VRRP MIB Management Objects

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [17]. This memo specifies a MIB module in a manner that is compliant with SMIv2 [5], and semantically identical to the SMIv1 definitions [2].

-- rfc2787.txt

Mobile Node NAI

AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.

-- rfc2794.txt

SBM (Subnet Bandwidth Manager)

This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee.

-- rfc2814.txt

TSWTCM

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner [RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB) [AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate (CTR) and Peak Target Rate (PTR).

-- rfc2859.txt

RADIUS Tunnel Authentication Attributes

This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.

-- rfc2868.txt

Root Name Server Operational Requirements

As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details.

-- rfc2870.txt

TCP and the IPv4 Precedence Field

This memo describes a conflict between TCP [RFC793] and DiffServ [RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict. Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.

-- rfc2873.txt

IPv6 DNS

This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.

-- rfc2874.txt

Extended RADIUS Practices

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment.

-- rfc2882.txt

ECN in IP Networks

This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated into RFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno, SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers. A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version.

-- rfc2884.txt

Router Renumbering for IPv6

IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site.

-- rfc2894.txt

Overview of the 1998 IAB Routing Workshop

This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.

-- rfc2902.txt

MALLOC Architecture

This document proposes a multicast address allocation architecture (MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism.

-- rfc2908.txt

The MASC Protocol

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group- specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.

-- rfc2909.txt

6BONE pTLA and pNLA Formats

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", [6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).

-- rfc2921.txt

TCP Problems with Path MTU Discovery

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU.

-- rfc2923.txt

Initial IPv6 Sub-TLA ID Assignments

This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned Numbers Authority (IANA) from the Internet Engineering Task Force (IETF) Internet Protocol Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses.

-- rfc2928.txt

The DNS TKEY RR

[RFC 2845] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.

-- rfc2930.txt

Protocol Independent Multicast MIB for IPv4

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 managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4.

-- rfc2934.txt

COPS Client MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. This memo includes a MIB module in a manner that is compliant to the SMIv2 [V2SMI].

-- rfc2940.txt

1999 IAB Network Layer Workshop

This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

-- rfc2956.txt

RSVP Refresh Overhead Reduction Extensions

This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.

-- rfc2961.txt

SNMP Payload Address Translation

This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15]. An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (Network Address Translator) in order to manage several potentially overlapping addressing realms. This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.

-- rfc2962.txt

Session Announcement Protocol

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.

-- rfc2974.txt

Mobile IP AAA Requirements

The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements for Authentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.

-- rfc2977.txt

Diffserv and Tunnels

This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.

-- rfc2983.txt

Network Access AAA Evaluation Criteria

This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ), Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.

-- rfc2989.txt

Next Steps for QoS Architecture

While there has been significant progress in the definition of Quality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.

-- rfc2990.txt

Multipath Issues

Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next- hop should be used for a given data packet.

-- rfc2991.txt

Architectural Implications of NAT

In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.

-- rfc2993.txt

Integrated Services Over Diffserv Networks

The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.

-- rfc2998.txt

IAB Wireless Workshop

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community. Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list.

-- rfc3002.txt

Notification Log MIB

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 managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

-- rfc3014.txt

31-Bit Prefixes on IPv4 Links

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.

-- rfc3021.txt

Protocol Complications with NAT

Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IP Network Address Translator (NAT) enroute to bridge the realms. The NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.

-- rfc3027.txt

MPLS Label Stack Encoding

"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.

-- rfc3032.txt

GIT and UUS Assignment for IP

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM.

-- rfc3033.txt

CGI for SIP

In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI is a good candidate for service creation in a SIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.

-- rfc3050.txt

IPv6 Tunnel Broker

The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999.

-- rfc3053.txt

Connection of IPv6 Domains via IPv4 Clouds

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address, even if combined with an IPv4 Network Address Translator (NAT).

-- rfc3056.txt

An Anycast Prefix for 6to4 Relay Routers

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix."

-- rfc3068.txt

LL Tunneling Mechanism for UDLs

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. The "receiver" uses a link-layer tunneling mechanism to forward datagrams to "feeds" over a separate bidirectional IP (Internet Protocol) network. As it is implemented at the link-layer, protocols in addition to IP may also be supported by this mechanism.

-- rfc3077.txt

Notification and Subscription for SLP

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.

-- rfc3082.txt

Diffserv per Domain Behaviors

The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes. The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge. This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions.

-- rfc3086.txt

OpenLDAP Root Service

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service.

-- rfc3088.txt

SOCKS-based IPv6/IPv4 Gateway Mechanism

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two "terminated" IPv4 and IPv6 connections at the "application layer" (the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished. Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by the SOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed.

-- rfc3089.txt

Firewall Enhancement Protocol

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse a Firewall. Our methodology is to layer any application layer Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, since HTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, since Firewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall.

-- rfc3093.txt

Robust Header Compression

This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards track Mobile IPv6 has been completed.

-- rfc3095.txt

Requirements for IP/UDP/RTP ROHC

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.

-- rfc3096.txt

RSIP: Framework

This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.

-- rfc3102.txt

RSIP Protocol Specification

This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.

-- rfc3103.txt

ATM SDP

This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. This list of conventions is meant to be exhaustive. Individual applications can use subsets of these conventions. Further, these conventions are meant to comply strictly with the SDP syntax as defined in RFC 2327.

-- rfc3108.txt

Service Location Protocol Modifications for IPv6

This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. This document does not describe how to use SLPv1 over IPv6 networks. There is at the time of this publication no implementation or deployment of SLPv1 over IPv6. It is RECOMMENDED that SLPv2 be used in general, and specifically on networks which support IPv6.

-- rfc3111.txt

Extensions to IPv6 Neighbor Discovery

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.

-- rfc3122.txt

DNS APL RR

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.

-- rfc3123.txt

AAA Protocol Evaluation Process

This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented.

-- rfc3127.txt

Requirements for KINK

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.

-- rfc3129.txt

DNSSEC Status Meeting Report

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.

-- rfc3130.txt

Dormant Mode Host Alerting Problem Statement

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. The results are specifically directed toward the task undertaken by the design team, and are not meant to be the definitive word on paging for all time, nor to be binding on Seamoby or other working groups, should the situation with regard to IP mobility protocols or radio link support undergo a major change.

-- rfc3132.txt

PILC - Performance Enhancing Proxies

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet.

-- rfc3135.txt

Per Hop Behavior Identification Codes

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836.

-- rfc3140.txt

IPv6-to-IPv4 Transport Relay Translator

The document describes an IPv6-to-IPv4 transport relay translator (TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic with IPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa. The memo talks about how to implement a TRT system using existing technologies. It does not define any new protocols.

-- rfc3142.txt

IPv6 Packets over IEEE 1394 Networks

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.

-- rfc3146.txt

Generic Routing Encapsulation over CLNS Networks

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS.

-- rfc3147.txt

Paging Requirements

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging.

-- rfc3154.txt

SPPI

This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. RFC 2748 defines the COPS protocol, and RFC 2749 describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module.

-- rfc3159.txt

RADIUS and IPv6

This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access.

-- rfc3162.txt

The Addition of ECN to IP

This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.

-- rfc3168.txt

Criteria for Evaluating NAS Protocols

This document defines requirements for protocols used by Network Access Servers (NAS).

-- rfc3169.txt

arpa Guidelines

This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. The "arpa" domain is used to support a class of infrastructural identifier spaces, providing a distributed database that translates elements of a structured name space derived from a protocol family to service names. The efficient and reliable operation of this DNS space is essential to the integrity of operation of various services within the Internet. The Internet Architecture Board (IAB) has the responsibility, in cooperation with the Internet Corporation for Assigned Names and Numbers (ICANN), to manage the "arpa" domain. This document describes the principles used by the IAB in undertaking this role.

-- rfc3172.txt

IP Payload Compression Protocol

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.

-- rfc3173.txt

RSVP Reservation Aggregation

This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.

-- rfc3175.txt

InMon Corporation's sFlow

This memo defines InMon Coporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector.

-- rfc3176.txt

IAB/IESG Recommendations on IPv6 Addresses September 2001

This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record.

-- rfc3177.txt

IPv6 Multihoming Support at Site Exit Routers

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently- practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates.

-- rfc3178.txt

GLOP Addressing in 233/8

This document defines the policy for the use of 233/8 for statically assigned multicast addresses.

-- rfc3180.txt

Securing L2TP using IPsec

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.

-- rfc3193.txt

An update on the H ratio

This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand.

-- rfc3194.txt

Terminology for Policy-Based Management

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).

-- rfc3198.txt

Extensions to RSVP for LSP Tunnels

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.

-- rfc3209.txt

Constraint-Based LSP Setup using LDP

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].

-- rfc3212.txt

SMIng Objectives

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.

-- rfc3216.txt

Telephony Routing over IP (TRIP)

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

-- rfc3219.txt

Commentary on Inter-Domain Routing

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.

-- rfc3221.txt

DNSSEC and IPv6 A6 requirements

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements.

-- rfc3226.txt

Middleboxes: Taxonomy and Issues

This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive.

-- rfc3234.txt

ROHC over PPP

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point-to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6.

-- rfc3241.txt

History and Context of ENUM Operational Decisions

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

-- rfc3245.txt

An Expedited Forwarding PHB

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598.

-- rfc3246.txt

Delay Bound alternative revision of RFC 2598

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB.

-- rfc3248.txt

Binary Lexical Octet Ad-hoc Transport

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.

-- rfc3252.txt

Distributing Authoritative Name Servers

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.

-- rfc3258.txt

A Message Bus for Local Coordination

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.

-- rfc3259.txt

New Terminology and Clarifications for Diffserv

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs.

-- rfc3260.txt

SIP: Session Initiation Protocol

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.

-- rfc3261.txt

An Offer/Answer Model Session Description Protocol

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).

-- rfc3264.txt

RMT Author Guidelines

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.

-- rfc3269.txt

MPLS Support of Differentiated Services

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.

-- rfc3270.txt

Overview and Principles of Internet TE

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.

-- rfc3272.txt

XML-Signature Syntax and Processing

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

-- rfc3275.txt

DSMON MIB

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 managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB.

-- rfc3287.txt

Differentiated Services MIB

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality.

-- rfc3289.txt

Diffserv Informal Management Model

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.

-- rfc3290.txt

GSMP MIB

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP).

-- rfc3295.txt

MIDCOM Architecture and Framework

A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group. There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP and H.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic.

-- rfc3303.txt

Unicast-Prefix-based IPv6 Multicast

This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol.

-- rfc3306.txt

IPv6 Multicast Addresses Guidelines

This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.

-- rfc3307.txt

L2TP Diffserv Extension

This document describes mechanisms which enable the Layer Two Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel. L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supporting Differentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination.

-- rfc3308.txt

Recommendations for IPv6 in 3GPP Standards September 2002

This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document.

-- rfc3314.txt

DHCP for IPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.

-- rfc3315.txt

IPv6 for Some 2G and 3G Cellular Hosts

As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.

-- rfc3316.txt

DiffServ QoS Policy Information Base

This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture. These provisioning classes can be used with other none Differentiated Services provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage.

-- rfc3317.txt

Framework Policy Information Base

This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning. Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each.

-- rfc3318.txt

DHCPv6 Options for SIP Servers

This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.

-- rfc3319.txt

Dual Stack Hosts Using BIA

This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications. The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation.

-- rfc3338.txt

iSCSI Requirements and Design Considerations

This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer. Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment.

-- rfc3347.txt

Reserved TLV Codepoints in ISIS

This document describes implementation codepoints within Intermediate System to Intermediate System (IS-IS) used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as Interior Gateway Protocol (IGP). This document summarizes all Table, Length and Value (TLV) codepoints that are being used by the protocol and its pending extensions.

-- rfc3359.txt

Representation of IPv6 Addresses in DNS

This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.

-- rfc3363.txt

Tradeoffs in DNS Support for IPv6

The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.

-- rfc3364.txt

Advice to Link Designers on Link ARQ

This document provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links. ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used.

-- rfc3366.txt

Context Transfer Problem Statement

In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service (QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility.

-- rfc3374.txt

Generic RRP Requirements

This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.

-- rfc3375.txt

IGMPv3

This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236.

-- rfc3376.txt

Encoding Long Options in DHCPv4

This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.

-- rfc3396.txt

Lower Layer Guidelines for Robust HC

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document.

-- rfc3409.txt

Architecture for SNMP Management Frameworks

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571.

-- rfc3411.txt

Transport Mappings for SNMP

This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906.

-- rfc3417.txt

Textual Conventions for Transport Addresses

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6.

-- rfc3419.txt

XACCT's CRANE Protocol Specification

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.

-- rfc3423.txt

Architectural and Policy Considerations

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed.

-- rfc3426.txt

SNMP over TCP Transport Mapping

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417.

-- rfc3430.txt

Network performance measurement

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations.

-- rfc3432.txt

MGCP 1.0

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents.

-- rfc3435.txt

PCIM Extensions

This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060.

-- rfc3460.txt

Role of the Domain Name System (DNS)

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.

-- rfc3467.txt

GMPLS Signaling Functional Description

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.

-- rfc3471.txt

GMPLS Signaling - CR-LDP Extensions

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.

-- rfc3472.txt

GMPLS Signaling - RSVP-TE Extensions

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.

-- rfc3473.txt

GMPLS RSVP-TE Usage and Extensions for ASON

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort.

-- rfc3474.txt

CR-LDP Extensions for ASON

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents.

-- rfc3475.txt

LDP & RSVP Extensions for Optical UNI Signaling

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions.

-- rfc3476.txt

TCP over 2.5G/3G

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet.

-- rfc3481.txt

Default Address Selection for IPv6

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.

-- rfc3484.txt

Cisco Systems RGMP

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.

-- rfc3488.txt

Basic Socket Interface Extensions for IPv6

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document.

-- rfc3493.txt

H.323 URL Scheme

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323- URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA).

-- rfc3508.txt

IPP URL Scheme

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service.

-- rfc3510.txt

The Security Flag in the IPv4 Header

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.

-- rfc3514.txt

PPP Bridging Control Protocol (BCP)

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D-1993 MAC Bridge. This document extends that specification by improving support for bridge control packets.

-- rfc3518.txt

NAT Traversal for Mobile IP

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic.

-- rfc3519.txt

Session Authorization Policy Element

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios.

-- rfc3520.txt

Link Selection sub-option

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent.

-- rfc3527.txt

Using XML-RPC in BEEP

XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers.

-- rfc3529.txt

NFS version 4 Protocol

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol.

-- rfc3530.txt

Bits Assignment of an IPv6 Address Block

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments.

-- rfc3531.txt

Robust ECN Signaling

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.

-- rfc3540.txt

Advanced Sockets API for IPv6

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable.

-- rfc3542.txt

IP Header Compression over PPP

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545.

-- rfc3544.txt

Enhanced Compressed RTP (CRTP)

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.

-- rfc3545.txt

Linux Netlink as an IP Services Protocol

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group.

-- rfc3549.txt

RTP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.

-- rfc3550.txt

Security Considerations Guidelines

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section.

-- rfc3552.txt

Multicast Address Allocation MIB

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 managed objects used for managing multicast address allocation.

-- rfc3559.txt

AODV Routing

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.

-- rfc3561.txt

IETF - JTC1 Agreement on IS-IS

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines.

-- rfc3563.txt

Requirements for Diff-Serv-aware TE

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.

-- rfc3564.txt

An Overview of SSM

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.

-- rfc3569.txt

IPv6 over MAPOS

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.

-- rfc3572.txt

Transition Scenarios for 3GPP Networks

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study.

-- rfc3574.txt

IANA Considerations for RADIUS

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). This document updates RFC 2865.

-- rfc3575.txt

RADIUS & EAP

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This document updates RFC 2869.

-- rfc3579.txt

IEEE 802.1X RADIUS

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.

-- rfc3580.txt

IPv6 Site-Multihoming Goals

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here.

-- rfc3582.txt

Mobile IP QoS Requirements

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.

-- rfc3583.txt

IPsec Configuration Policy Model

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe).

-- rfc3585.txt

IPv6 Global Unicast Address Format

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic.

-- rfc3587.txt

Diameter Based Protocol

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations.

-- rfc3588.txt

Source Address Selection for MLD Protocol

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.

-- rfc3590.txt

Textual Conventions for IPv6 Flow Label

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.

-- rfc3595.txt

DNS Extensions to Support IPv6

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.

-- rfc3596.txt

RTCP attribute in SDP

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

-- rfc3605.txt

RTCP XR

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

-- rfc3611.txt

URI Scheme for TFTP

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

-- rfc3617.txt

The TUNNEL Profile

This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.

-- rfc3620.txt

Optimized Link State Routing

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

-- rfc3626.txt

/127 Prefix Length Considered Harmful

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

-- rfc3627.txt

VeriSign RRP v2.0.0

This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.

-- rfc3632.txt

IPv6 Prefix Options for DHCPv6

The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

-- rfc3633.txt

FC Frame Encapsulation

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

-- rfc3643.txt

Policy QoS Information Model

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

-- rfc3644.txt

DNS Configuration Options for DHCPv6

This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

-- rfc3646.txt

Handle System Service Definition

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

-- rfc3651.txt

ForCES Requirements

This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

-- rfc3654.txt

Lower Effort PDB

This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

-- rfc3662.txt

QoS Device Datapath Info Model

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository.

-- rfc3670.txt

.sex Considered Dangerous

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

-- rfc3675.txt

Multicast Source Filter API

The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

-- rfc3678.txt

Unused DHCP Option Codes

Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

-- rfc3679.txt

Delegation of E.F.F.3.IP6.ARPA

This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.

-- rfc3681.txt

TBRPF

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.

-- rfc3684.txt

Using AES Counter Mode With IPsec ESP

This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

-- rfc3686.txt

IPv6 Flow Label Specification

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.

-- rfc3697.txt

6bone Phaseout Plan

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.

-- rfc3701.txt

Ingress Filtering for Multihomed Networks

BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827.

-- rfc3704.txt

SRTP

This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).

-- rfc3711.txt

IAB Concerns Regarding Congestion Control

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic.

-- rfc3714.txt

IPsec-NAT Compatibility Requirements

This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses.

-- rfc3715.txt

iSCSI

This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI.

-- rfc3720.txt

iSCSI Naming and Discovery

This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.

-- rfc3721.txt

String Profile for iSCSI Names

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared.

-- rfc3722.txt

Securing Block Storage Protocols over IP

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.

-- rfc3723.txt

Future of End-to-End

The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.

-- rfc3724.txt

Requirements for Signaling Protocols

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility.

-- rfc3726.txt

Stateless DHCP Service for IPv6

Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP.

-- rfc3736.txt

WEBRC Building Block

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.

-- rfc3738.txt

Multicast Group Security Architecture

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.

-- rfc3740.txt

Differentiated Services Configuration MIB

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB.

-- rfc3747.txt

EAP

This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.

-- rfc3748.txt

Unmanaged Networks IPv6 Transition Scenarios

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6.

-- rfc3750.txt

Mobility Related Terminology

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology.

-- rfc3753.txt

IP Multicast in DS Networks

This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.

-- rfc3754.txt

IPv6 ND Trust Models and Threats

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.

-- rfc3756.txt

OWAMP Requirements

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.

-- rfc3763.txt

Requirements IPv6 Prefix Delegation

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site").

-- rfc3769.txt

Mobility Support in IPv6

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.

-- rfc3775.txt

Home Agent IPsec

Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.

-- rfc3776.txt

X.509 Extensions for IP Addr and AS ID

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions.

-- rfc3779.txt

Introduction to the IPv4 Address in the IETF

This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results.

-- rfc3789.txt

IPv4 Addresses in the IETF Internet Area

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

-- rfc3790.txt

IPv4 Addresses in the IETF Routing Area

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

-- rfc3791.txt

IPv4 Addresses in the IETF Security Area

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

-- rfc3792.txt

IPv4 Addresses in the IETF Sub-IP Area

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

-- rfc3793.txt

IPv4 Addresses in the IETF Transport Area

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

-- rfc3794.txt

IPv4 Addresses in the IETF Application Area

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience.

-- rfc3795.txt

IPv4 in the IETF Operations & Management Area

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.

-- rfc3796.txt

PPVPN

This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.

-- rfc3809.txt

MLDv2 for IPv6

This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.

-- rfc3810.txt

MPLS TC MIB

This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.

-- rfc3811.txt

MPLS-TE-STD-MIB

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 managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE).

-- rfc3812.txt

MPLS LSR MIB

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR).

-- rfc3813.txt

MPLS FTN MIB

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 managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS).

-- rfc3814.txt

MPLS LDP MIB

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 managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP).

-- rfc3815.txt

IANA Considerations for PPP

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served."

-- rfc3818.txt

Advice for Internet Subnetwork Designers

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet.

-- rfc3819.txt

FCIP

Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.

-- rfc3821.txt

UDP-Lite Protocol

This document describes the Lightweight User Datagram Protocol (UDP- Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP.

-- rfc3828.txt

DNS Threat Analysis

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.

-- rfc3833.txt

A ROHC Profile for IP

The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.

-- rfc3843.txt

IPv6 Documentation Address

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation.

-- rfc3849.txt

SUA

This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture.

-- rfc3868.txt

Research Funding Recommendations

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.

-- rfc3869.txt

Operational Security Requirements

This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.

-- rfc3871.txt

MIB for TRIP

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices.

-- rfc3872.txt

SCTP MIB using SMIv2

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP.

-- rfc3873.txt

CGI Version 1.1

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems.

-- rfc3875.txt

Alarm MIB

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 management objects used for modelling and storing alarms.

-- rfc3877.txt

Deprecating Site Local Addresses

This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.

-- rfc3879.txt

CPL

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.

-- rfc3880.txt

IPsec Transport Mode for Dynamic Routing

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).

-- rfc3884.txt

Bandwidth Modifier for SDP

This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear.

-- rfc3890.txt

NIS Configuration Options for DHCPv6

This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name.

-- rfc3898.txt

DNS IPv6 Transport Guidelines

This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks.

-- rfc3901.txt

Unmanaged Networks Transition Tools

This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.

-- rfc3904.txt

PWE3 Requirements

This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.

-- rfc3916.txt

IPFIX Requirements

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.

-- rfc3917.txt

Methodology for IP Multicast Benchmarking

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.

-- rfc3918.txt

RMON Protocol Identifiers for IPv6 and MPLS

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895]. This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information.

-- rfc3919.txt

XMPP Core

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.

-- rfc3920.txt

XMPP IM

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.

-- rfc3921.txt

Vendor-Identifying Vendor Options

The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity.

-- rfc3925.txt

FLUTE

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.

-- rfc3926.txt

IPv4 Link-Local

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.

-- rfc3927.txt

L2TPv3

This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated.

-- rfc3931.txt

GMPLS Architecture

Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane.

-- rfc3945.txt

Negotiation of NAT-Traversal in the IKE

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE).

-- rfc3947.txt

UDP Encapsulation of IPsec ESP Packets

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE).

-- rfc3948.txt

Cisco Systems NetFlow Services Export V9

This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics.

-- rfc3954.txt

Evaluation of Candidate Protocols for IPFIX

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.

-- rfc3955.txt

The RP Address in IPv6 Multicast Address

This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.

-- rfc3956.txt

NEMO Basic Support Protocol

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.

-- rfc3963.txt

Security Considerations for 6to4

The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.

-- rfc3964.txt

A Traffic Engineering (TE) MIB

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 managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths.

-- rfc3970.txt

SEcure Neighbor Discovery

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.

-- rfc3971.txt

Cryptographically Generated Addresses

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure.

-- rfc3972.txt

PIM - Dense Mode

This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information.

-- rfc3973.txt

SMTP in Dual Stack Environments

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. This document does not define any new protocol.

-- rfc3974.txt

IRIS-Core

This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs.

-- rfc3981.txt

IRIS-Dreg

This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars.

-- rfc3982.txt

PWE3 Architecture

This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.

-- rfc3985.txt

URI Generic Syntax

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.

-- rfc3986.txt

Internationalized Resource Identifiers

This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

-- rfc3987.txt

Internet Network Address Conventions

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.

-- rfc4001.txt

Diameter MIP

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.

-- rfc4004.txt

Diameter Network Access Server Application

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations. The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol.

-- rfc4005.txt

Diameter Credit-Control Application

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.

-- rfc4006.txt

IPv6 Scoped Address Architecture

This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.

-- rfc4007.txt

NAT MIB

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function.

-- rfc4008.txt

Policy Based Management MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment.

-- rfc4011.txt

RPSLng

This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet.

-- rfc4012.txt

RADIUS Attributes Suboption

The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client.

-- rfc4014.txt

PANA Threat Analysis

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.

-- rfc4016.txt

iSCSI and SLPv2

The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide.

-- rfc4018.txt

ROHC: Profiles for UDP-Lite

This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol- Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP- Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.

-- rfc4019.txt

MIB for TCP

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 managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012.

-- rfc4022.txt

Encapsulating MPLS in IP or GRE

Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances.

-- rfc4023.txt

Storing IPsec Keying Material in DNS

This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.

-- rfc4025.txt

Provider Provisioned VPN Terminology

The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive.

-- rfc4026.txt

ISP Networks IPv6 Scenarios

This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified.

-- rfc4029.txt

Service Requirements for L3 PPVPNs

This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.

-- rfc4031.txt

DNS Security Introduction and Requirements

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.

-- rfc4033.txt

DNSSEC Protocol Modifications

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.

-- rfc4035.txt

DOCSIS Subscriber Management MIB

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 a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification.

-- rfc4036.txt

Application Aspects of IPv6 Transition

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period.

-- rfc4038.txt

Rapid Commit Option for DHCPv4

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration.

-- rfc4039.txt

Efficient Multicast Traffic in L2TP

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels.

-- rfc4045.txt

RFC 1888 Is Obsolete

This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty.

-- rfc4048.txt

IPv6 Enterprise Network Scenarios

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.

-- rfc4057.txt

PANA Requirements

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.

-- rfc4058.txt

Seamoby IANA Allocations

The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.

-- rfc4065.txt

Candidate Access Router Discovery (CARD)

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD.

-- rfc4066.txt

Context Transfer Protocol (CXTP)

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.

-- rfc4067.txt

Diameter EAP Application

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server.

-- rfc4072.txt

Common Misbehavior Against DNS Queries

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects.

-- rfc4074.txt

SNTP Configuration Option for DHCPv6

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client.

-- rfc4075.txt

Renumbering for Stateless DHCPv6

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.

-- rfc4076.txt

NSIS Framework

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols. This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application.

-- rfc4080.txt

Security Threats for NSIS

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.

-- rfc4081.txt

3GPP R5 Requirements on SIP

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.

-- rfc4083.txt

IP Service Terms

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.

-- rfc4084.txt

Embedding IP Addresses Considered Harmful

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard.

-- rfc4085.txt

IP Tunnel MIB

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667.

-- rfc4087.txt

RSVP-TE Fast Reroute

This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network.

-- rfc4090.txt

MIPv4 VPN Traversal Problem Statement

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.

-- rfc4093.txt

Analysis of QoS Signaling

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.

-- rfc4094.txt

MIDCOM Protocol Evaluation

This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.

-- rfc4097.txt

Terminology for Benchmarking BGP

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.

-- rfc4098.txt

PCELS

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703.

-- rfc4104.txt

A Framework for L3 PPVPNs

This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.

-- rfc4110.txt

UDP MIB

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 managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454.

-- rfc4113.txt

IPv4 Multihoming

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).

-- rfc4116.txt

Kerberos V5

This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.

-- rfc4120.txt

DOCSIS BPI Plus MIB

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 a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems.

-- rfc4131.txt

DNA Goals

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.

-- rfc4135.txt

IANA IPv6 Registry

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format.

-- rfc4147.txt

SSPM-MIB

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 Synthetic Sources for Performance Monitoring (SSPM) algorithms.

-- rfc4149.txt

ip6.int

This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations.

-- rfc4159.txt

Requirements on ROHC TCP/IP

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.

-- rfc4163.txt

Context Replication for ROHC Profiles

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.

-- rfc4164.txt

Telephony Signalling over SCTP AS

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.

-- rfc4166.txt

Internet Storage Name Service (iSNS)

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.

-- rfc4171.txt

Internet Fibre Channel Networking

This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.

-- rfc4172.txt

iSCSI Bootstrapping

Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.

-- rfc4173.txt

Multi6 Architecture

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.

-- rfc4177.txt

Removing a Restriction on the use of MPLS

The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. This document updates RFC 3032.

-- rfc4182.txt

DNSNET

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.

-- rfc4183.txt

IP Telephony Framework

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.

-- rfc4190.txt

Router Preferences and More-Specific Routes

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more- specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables.

-- rfc4191.txt

Renumbering IPv6 Networks

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.

-- rfc4192.txt

Unique Local IPv6 Unicast Addresses

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet.

-- rfc4193.txt

Link Bundling in MPLS-TE

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description.

-- rfc4201.txt

Link Management Protocol (LMP)

For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.

-- rfc4204.txt

Basic IPv6 Transition Mechanisms

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893.

-- rfc4213.txt

IPv6 Transition in 3GPP Networks

This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.

-- rfc4215.txt

Threats to IPv6 Multihoming Solutions

This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.

-- rfc4218.txt

MULTI6 Solution Questionnaire

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.

-- rfc4219.txt

MPLS TE Link MIB Module

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 managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document.

-- rfc4220.txt

MPLS Management Overview

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management.

-- rfc4221.txt

Prioritized Treatment

This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures.

-- rfc4222.txt

Mobile IPv6 RO Security Design

This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002. The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs.

-- rfc4225.txt

Using SOAP in BEEP

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.

-- rfc4227.txt

Dual Stack Access Service

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.

-- rfc4241.txt

Information Refresh Time Option for DHCPv6

This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.

-- rfc4242.txt

Requirements for Header Compression over MPLS November 2005

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario.

-- rfc4247.txt

SSH Connection Protocol

Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.

-- rfc4254.txt

IP Transport over MPEG-2 Networks

This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.

-- rfc4259.txt

802.11 Fast Handover

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.

-- rfc4260.txt

BGP-4

This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771.

-- rfc4271.txt

DHCP Options for BMCS

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes.

-- rfc4280.txt

Mobile Node Identifier Option for MIPv6

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header.

-- rfc4283.txt

Authentication Protocol for Mobile IPv6

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.

-- rfc4285.txt

Multicast Router Discovery

The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.

-- rfc4286.txt

IPv6 Addressing Architecture

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture".

-- rfc4291.txt

IP Forwarding Table MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096.

-- rfc4292.txt

IP MIB

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 managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466.

-- rfc4293.txt

IPv6 Node Requirements

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.

-- rfc4294.txt

MOBILEIPV6-MIB

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity.

-- rfc4295.txt

Security Architecture for IP

This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998).

-- rfc4301.txt

IP Authentication Header

This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).

-- rfc4302.txt

IP Encapsulating Security Payload (ESP)

This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).

-- rfc4303.txt

Using AEC CCM Mode with IPsec ESP

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.

-- rfc4309.txt

IPv6 Host-to-Router Load Sharing

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.

-- rfc4311.txt

Opportunistic Encryption using IKE

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.

-- rfc4322.txt

IPCDN DOCSIS QoS MIB

This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0.

-- rfc4323.txt

ULE for IP over MPEG-2/DVB

The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.

-- rfc4326.txt

IP over Fibre Channel

This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document obsoletes RFC 2625 and RFC 3831.

-- rfc4338.txt

IPv6 Host Configuration of DNS Server

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.

-- rfc4339.txt

Datagram Congestion Control Protocol (DCCP)

The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.

-- rfc4340.txt

DNS Case Insensitivity Clarification

Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181.

-- rfc4343.txt

Datagram Transport Layer Security

This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.

-- rfc4347.txt

RSA/SHA-1 Signatures within ESP and AH

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet.

-- rfc4359.txt

Node-specific Identifiers for DHCPv4

This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers.

-- rfc4361.txt

A Link-Layer Assisted ROHC RTP

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes.

-- rfc4362.txt

Applicability Statement for BGP/MPLS IP VPNs February 2006

This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section.

-- rfc4365.txt

iFCP MIB

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP.

-- rfc4369.txt

Detecting MPLS Data Plane Failures

This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply.

-- rfc4379.txt

Teredo

We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".

-- rfc4380.txt

PW3 Control Word for Use over an MPLS PSN

This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.

-- rfc4385.txt

DHCP Leasequery

A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.

-- rfc4388.txt

ND Proxy

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.

-- rfc4389.txt

IP over InfiniBand (IPoIB)

This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links.

-- rfc4391.txt

IPoIB Architecture

InfiniBand is a high-speed, channel-based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents.

-- rfc4392.txt

Transport Network View of LMP

The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.

-- rfc4394.txt

Storing Certificates in the DNS

Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538.

-- rfc4398.txt

FCIP MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks.

-- rfc4404.txt

Sender ID: Authenticating E-Mail

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.

-- rfc4406.txt

Sender Policy Framework (SPF)

E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.

-- rfc4408.txt

Selectively Reliable Multicast Protocol

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application.

-- rfc4410.txt

TCP/IP Field Behavior

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers.

-- rfc4413.txt

ENUM Registry Type for IRIS

This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries.

-- rfc4414.txt

Host Identity Protocol (HIP) Architecture

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding.

-- rfc4423.txt

Optimistic DAD

Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers.

-- rfc4429.txt

KINK

This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations.

-- rfc4430.txt

Fibre Channel Name Server MIB

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 managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes.

-- rfc4438.txt

IEEE 802/IETF Relationship

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.

-- rfc4441.txt

ICMPv6 (ICMP for IPv6)

This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6).

-- rfc4443.txt

IS-IS MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks.

-- rfc4444.txt

Encapsulation of Ethernet over MPLS

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service.

-- rfc4448.txt

Shared Data for Precomputable Kbm

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.

-- rfc4449.txt

Packet Size Issues in Network Tunnels

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.

-- rfc4459.txt

SCTP Errata

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided.

-- rfc4460.txt

Signaling Requirements for P2MP TE MPLS LSPs

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution-specific details or application-specific requirements in this document. The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS.

-- rfc4461.txt

MRCP by Cisco, Nuance, and Speechworks

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol).

-- rfc4463.txt

Considerations with IPv6 DNS

This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.

-- rfc4472.txt

DHCP: Dual-Stack Issues

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.

-- rfc4477.txt

SIP Guidelines

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.

-- rfc4485.txt

MIPv6 and Firewalls

This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks. The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.

-- rfc4487.txt

Link-Scoped IPv6 Multicast

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast- prefix-based IPv6 multicast addresses. This memo updates RFC 3306.

-- rfc4489.txt

RSVP Bandwidth Reduction

This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205.

-- rfc4495.txt

Interworking between SIP and QSIG

This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.

-- rfc4497.txt

SIP Telephony Device Requirements

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings.

-- rfc4504.txt

LDAP Authentication Methods

This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation. This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism. This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes. This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830.

-- rfc4513.txt

LDAP: Uniform Resource Locator

This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed.

-- rfc4516.txt

GSAKMP

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys.

-- rfc4535.txt

NEC's SIMCO Protocol Version 3.0

This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.

-- rfc4540.txt

IGMP and MLD Snooping Switches Considerations

This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.

-- rfc4541.txt

ETS in an IP Network

RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations.

-- rfc4542.txt

iSCSI MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP).

-- rfc4544.txt

IPS Authorization MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods.

-- rfc4545.txt

DOCSIS 2.0 Radio Frequency (RFI) MIB

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 a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS).

-- rfc4546.txt

Internet Code Point (ICP) Assignments

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments.

-- rfc4548.txt

Authentication/Confidentiality for OSPFv3

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header.

-- rfc4552.txt

Structure-Agnostic TDM over Packet

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing.

-- rfc4553.txt

VLANs for IPv4-IPv6 Coexistence

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.

-- rfc4554.txt

MOBIKE Protocol

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.

-- rfc4555.txt

Node-ID Based RSVP Hello

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.

-- rfc4558.txt

REMOPS MIB

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.

-- rfc4560.txt

Definition of RRO Node-Id Sub-Object

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method.

-- rfc4561.txt

MAC-Forced Forwarding

This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment. The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts.

-- rfc4562.txt

CAPWAP Objectives

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs.

-- rfc4564.txt

Evaluation of Candidate CAPWAP Protocols

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.

-- rfc4565.txt

SDP

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

-- rfc4566.txt

SDP Source Filters

This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session.

-- rfc4570.txt

Relay Agent Subscriber-ID

This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure.

-- rfc4580.txt

Sockets for API for Mobile IPv6

This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6. Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications.

-- rfc4584.txt

RTP Retransmission Payload Format

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.

-- rfc4588.txt

Guidelines for DiffServ Service Classes

This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.

-- rfc4594.txt

IKEv2 in FC-SP

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.

-- rfc4595.txt

PIM-SM Specification

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. This document obsoletes RFC 2362, an Experimental version of PIM-SM.

-- rfc4601.txt

PIM-SM Proposed Standard Req. Analysis

This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard.

-- rfc4602.txt

IGMPv3/MLDv2 for SSM

The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.

-- rfc4604.txt

IGMP/MLD-Based Multicast Forwarding

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information.

-- rfc4605.txt

Source-Specific Multicast

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source- specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.

-- rfc4607.txt

Source-Specific PIM in 232/8

IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range.

-- rfc4608.txt

PIM-SM Multicast Routing Security

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats.

-- rfc4609.txt

MSDP Deployment Scenarios

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM).

-- rfc4611.txt

TCP Roadmap

This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

-- rfc4614.txt

Transport of PPP/HDLC over MPLS

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire.

-- rfc4618.txt

IPv6 Node Information Queries

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.

-- rfc4620.txt

Design of the MOBIKE Protocol

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.

-- rfc4621.txt

PWE3 Fragmentation and Reassembly

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.

-- rfc4623.txt

MSDP MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers.

-- rfc4624.txt

LMP-MIB Module

This document provides minor corrections to and obsoletes RFC 4327. 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 managed objects for modeling the Link Management Protocol (LMP).

-- rfc4631.txt

DOCSIS Cable Device MIB

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 a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems. This memo obsoletes RFC 2669.

-- rfc4639.txt

PS Bootstrapping Mobile IPv6

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping.

-- rfc4640.txt

Relay Agent Remote-ID

This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046.

-- rfc4649.txt

MIP6 Route Optimization Enhancements

This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.

-- rfc4651.txt

Evaluation of Routing Protocols against ASON

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T.

-- rfc4652.txt

One-way Active Measurement Protocol

The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements.

-- rfc4656.txt

BGP-MPLS IP VPN Extension for IPv6 VPN

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP". This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document.

-- rfc4659.txt

Framework for Layer 2 VPNs

This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.

-- rfc4664.txt

Service Requirements for L2VPNs

This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives.

-- rfc4665.txt

RADIUS Auth Client MIB (IPv6)

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects.

-- rfc4668.txt

RADIUS Auth Server MIB (IPv6)

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers. This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects.

-- rfc4669.txt

RADIUS Acct Client MIB (IPv6)

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients. This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects.

-- rfc4670.txt

RADIUS Acct Server MIB (IPv6)

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers. This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects.

-- rfc4671.txt

RADIUS Dynamic Authorization Client MIB

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 the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576.

-- rfc4672.txt

RADIUS Dynamic Authorization Server MIB

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 the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576.

-- rfc4673.txt

Requirements for PCE Discovery

This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.

-- rfc4674.txt

SASPv1

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.

-- rfc4678.txt

DSL Forum RADIUS VSA

This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum. These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products.

-- rfc4679.txt

IPCDN MTA MIB

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 a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices.

-- rfc4682.txt

Route Target (RT) Constrain

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364.

-- rfc4684.txt

Terminology for Traffic Control Mechanisms

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.

-- rfc4689.txt

IPv6 Host Density Metric

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches.

-- rfc4692.txt

Observed DNS Resolution Misbehavior

This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers.

-- rfc4697.txt

IRIS Address Registry Type

This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries.

-- rfc4698.txt

The DHCID RR

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR.

-- rfc4701.txt

Resolution of FQDN Conflicts

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts.

-- rfc4703.txt

The DHCPv6 Client FQDN Option

This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments.

-- rfc4704.txt

GigaBeam Radio Link Encryption

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.

-- rfc4705.txt

RAQMON Framework

There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications.

-- rfc4710.txt

RAQMON MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring.

-- rfc4711.txt

Transport Mappings for RAQMON PDU

This memo specifies two transport mappings of the Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).

-- rfc4712.txt

Encapsulation for ATM over MPLS

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service.

-- rfc4717.txt

Transport of Ethernet Frames over L2TPv3

This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network.

-- rfc4719.txt

Experimental Values in Headers

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents.

-- rfc4727.txt

The Dynamic Source Routing Protocol

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop- free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.

-- rfc4728.txt

DoS Considerations

This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.

-- rfc4732.txt

MPLS-TE Loosely Routed LSP

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.

-- rfc4736.txt

Packet Reordering Metrics

This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation.

-- rfc4737.txt

OSPFv2 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B.

-- rfc4750.txt

Connected Mode IPoIB

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand.

-- rfc4755.txt

Multiprotocol Extensions for BGP-4

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.

-- rfc4760.txt

BGP Auto-Discovery and Signaling for VPLS

Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network.

-- rfc4761.txt

The IDMEF

The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided.

-- rfc4765.txt

IDME Requirements

The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements.

-- rfc4766.txt

IANA IPv6 Registry

This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry.

-- rfc4773.txt

Procedures for Protocol Extensions

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF. This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.

-- rfc4775.txt

DHCP Civic

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.

-- rfc4776.txt

OPSEC Practices

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.

-- rfc4778.txt

ISP IPv6 Deployment Scenarios in BB

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.

-- rfc4779.txt

Graceful Restart Mechanism for BGP

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.).

-- rfc4781.txt

Quick-Start for TCP and IP

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request. This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.

-- rfc4782.txt

GMPLS - Communication of Alarm Information

This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473.

-- rfc4783.txt

Anycast BCP

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast.

-- rfc4786.txt

NAT UDP Unicast Requirements

This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.

-- rfc4787.txt

EAP-POTP

This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2).

-- rfc4793.txt

LLMNR

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.

-- rfc4795.txt

6PE

This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration.

-- rfc4798.txt

GMPLS TE MIB

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 managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering.

-- rfc4802.txt

RSVP Aggregation over MPLS TE Tunnels

RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels.

-- rfc4804.txt

Reqs for IPsec Certificate Mgmt Profile

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements.

-- rfc4809.txt

Hash and Stuffing

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.

-- rfc4814.txt

Corrections and Clarifications to RFC 3095

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided.

-- rfc4815.txt

MPLS over L2TPv3

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead.

-- rfc4817.txt

Delegated-IPv6-Prefix Attribute

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter.

-- rfc4818.txt

Packetization Layer Path MTU Discovery

This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.

-- rfc4821.txt

IP over SFSS

This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).

-- rfc4824.txt

TFRC: The SP Variant

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently. Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth.

-- rfc4828.txt

NETLMM Problem Statement

Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.

-- rfc4830.txt

NETLMM Goals

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.

-- rfc4831.txt

Security Threats to NETLMM

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself.

-- rfc4832.txt

Timezone Options for DHCP

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated.

-- rfc4833.txt

L3VPN Mcast Reqs

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.

-- rfc4834.txt

Delay-Tolerant Networking Architecture

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.

-- rfc4838.txt

Multiple Encapsulation Methods Harmful

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.

-- rfc4840.txt

Cryptographic Hash IDentifiers (ORCHID)

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus.

-- rfc4843.txt

IPv6 Enterprise Network Analysis

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.

-- rfc4852.txt

Document Shepherding to Publication

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role.

-- rfc4858.txt

Generic Aggregate RSVP Reservations

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.

-- rfc4860.txt

Neighbor Discovery in IPv6

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.

-- rfc4861.txt

IPv6 Stateless Address Autoconfiguration

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.

-- rfc4862.txt

Local Network Protection for IPv6

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.

-- rfc4864.txt

Enhanced Route Optimization

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead.

-- rfc4866.txt

RSVP-TE Extensions for E2E GMPLS Recovery

This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426.

-- rfc4872.txt

Exclude Routes - Extension to RSVP-TE

This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document.

-- rfc4874.txt

Extensions to RSVP-TE for P2MP TE LSPs

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document.

-- rfc4875.txt

Mobile IPv6 with IKEv2 and IPsec

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2.

-- rfc4877.txt

MIP6 Location Privacy

In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.

-- rfc4882.txt

Benchmarking Terms for RR Capable Routers

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements.

-- rfc4883.txt

Multi-Part ICMP Messages

This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443.

-- rfc4884.txt

NEMO Terminology

This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements.

-- rfc4885.txt

NEMO Goals

Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.

-- rfc4886.txt

Home Network Models with NEMO Basic

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists.

-- rfc4887.txt

NEMO RO Problem Statement

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.

-- rfc4888.txt

NEMO RO Space Analysis

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization.

-- rfc4889.txt

ICMPv6 Filtering Recommendations

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks.

-- rfc4890.txt

IPsec with IPv6-in-IPv4 Tunnels

This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework.

-- rfc4891.txt

TCP Extended Statistics MIB

This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature.

-- rfc4898.txt

Header Compression over MPLS Protocol

This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to- point link.

-- rfc4901.txt

Multi-Link Subnet Issues

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach.

-- rfc4903.txt

Link Indications

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.

-- rfc4907.txt

Multihoming for Fixed Network

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy.

-- rfc4908.txt

6LoWPAN Problems and Goals

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only.

-- rfc4919.txt

Crankback Signaling Extensions

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time.

-- rfc4920.txt

QoS in a Nested VPN

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998.

-- rfc4923.txt

Reflections on Internet Transparency

This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts.

-- rfc4924.txt

Softwire Problem Statement

This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.

-- rfc4925.txt

Avoiding ECMP Treatment in MPLS Networks

This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.

-- rfc4928.txt

iSNS MIB

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server.

-- rfc4939.txt

IANA Considerations for OSPF

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.

-- rfc4940.txt

Privacy Extensions to Autoconf

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

-- rfc4941.txt

IPv6 Security Overview

The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

-- rfc4942.txt

On-Link Assumption Harmful

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.

-- rfc4943.txt

IPv6 over IEEE 802.15.4

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.

-- rfc4944.txt

PKI Profile for IKE/ISAKMP/PKIX

The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.

-- rfc4945.txt

AR Mechanisms for IP over MPEG-2 Networks

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.

-- rfc4947.txt

Unwanted Traffic

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic.

-- rfc4948.txt

Internet Security Glossary, Version 2

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.

-- rfc4949.txt

ICMP MPLS

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed.

-- rfc4950.txt

L2 Notifications for DNA

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies.

-- rfc4957.txt

ETS Single Domain Framework

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.

-- rfc4958.txt

Stream Control Transmission Protocol

This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

-- rfc4960.txt

IPv4 Reassembly Errors at High Data Rates

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.

-- rfc4963.txt

CableLabs-IETF Collaboration

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs).

-- rfc4965.txt

IPv6 Link Models for IEEE 802.16

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.

-- rfc4968.txt

OSPF Capability Extensions

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).

-- rfc4970.txt

IS-IS Extensions for Advertising Router Info

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.

-- rfc4971.txt

Discovery of MPLS LSR TE Mesh Membership

The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs.

-- rfc4972.txt

GMPLS RSVP-TE Signaling Extensions

In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching.

-- rfc4974.txt

MSRP Relays

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.

-- rfc4976.txt

Problem Statement: Dual Stack Mobility

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.

-- rfc4977.txt

Analysis of Multihoming in NEMO

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues.

-- rfc4980.txt

Multiple Hash Support in CGAs

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.

-- rfc4982.txt

IAB Workshop on Routing & Addressing

This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work.

-- rfc4984.txt

TCP SYN Flooding

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.

-- rfc4987.txt

MIP4 Fast Handovers

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.

-- rfc4988.txt

Use of Addresses in GMPLS Networks

This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment. The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs.

-- rfc4990.txt

Relay Agent ERO

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.

-- rfc4994.txt

ROHC-TCP

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

-- rfc4996.txt

ROHC-FN

This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work.

-- rfc4997.txt

Internet Official Protocol Standards

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred. For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily.

-- rfc5000.txt

DNS NSID

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality.

-- rfc5001.txt

DHCPv6 Leasequery

This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6.

-- rfc5007.txt

Socket API for Source Address Selection

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses.

-- rfc5014.txt

Bidirectional PIM

This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous- Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events.

-- rfc5015.txt

BFCP

This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS).

-- rfc5018.txt

MIP6 Bootstrapping in Split Scenario

A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario.

-- rfc5026.txt

LDP Specification

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.

-- rfc5036.txt

LDP Implementation Survey Results

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard.

-- rfc5038.txt

MPA Framing for TCP

Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level.

-- rfc5044.txt

Xcast Concepts and Options

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.

-- rfc5058.txt

BSR Mechanism for PIM

This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure.

-- rfc5059.txt

PIM MIB

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 managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934.

-- rfc5060.txt

SCTP Dynamic Address Reconfiguration

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer w