Current Internet-Drafts
This summary sheet provides a short synopsis of each Internet-Draft
available within the "internet-drafts" directory at the shadow
sites directory. These drafts are listed alphabetically by working
group acronym and start date.
IP over IEEE 802.16 Networks (16ng)
-----------------------------------
"Transmission of IP over Ethernet over IEEE 802.16 Networks", HongSeok Jeon,
18-Nov-08, <draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.txt>
This document describes the transmission of IPv4 over Ethernet as
well as IPv6 over Ethernet in an access network deploying the IEEE
802.16 cellular radio transmission technology. The Ethernet on top
of IEEE 802.16 is realized by bridging connections which the IEEE
802.16 provides between a base station and its associated subscriber
stations. Due to the resource constraints of radio transmission
systems and the limitations of the IEEE 802.16 MAC functionality for
the realization of an Ethernet, the transmission of IP over Ethernet
over IEEE 802.16 may considerably benefit by adding IP specific
support functions in the Ethernet over IEEE 802.16 while maintaining
full compatibility with standard IP over Ethernet behavior.
"Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer",
Syam Madanapalli, Soohong Daniel Park, Samita Chakrabarti, Gabriel
Montenegro, 2-Nov-08, <draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt>
IEEE 802.16 is an air interface specification for wireless broadband
access. IEEE 802.16 has specified multiple service specific
convergence sublayers for transmitting upper layer protocols. The
packet CS (Packet Convergence Sublayer) is used for the transport of
all packet-based protocols such as Internet Protocol (IP), IEEE 802.3
(Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the
Packet CS enables the transport of IPv4 packets directly over the
IEEE 802.16 MAC.
This document specifies the frame format, the Maximum Transmission
Unit (MTU) and address assignment procedures for transmitting IPv4
packets over the IP-specific part of the Packet Convergence Sublayer
of IEEE 802.16.
IPv6 over Low power WPAN (6lowpan)
----------------------------------
"Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui,
Pascal Thubert, 17-Nov-08, <draft-ietf-6lowpan-hc-03.txt>
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. This
document specifies compression of multicast addresses and a framework
for compressing next headers. This framework specifies UDP
compression and is prepared for additional transports.
"Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas
Chevrollier, Dominik Kaspar, JP Vasseur, 3-Nov-08,
<draft-ietf-6lowpan-usecases-01.txt>
This document investigates potential application scenarios and use
cases for low-power wireless personal area networks (LoWPANs).
"Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui,
Samita Chakrabarti, Erik Nordmark, 18-Nov-08, <draft-ietf-6lowpan-nd-00.txt>
This document specifies Neighbor Discovery optimized for 6LoWPAN.
The 6LoWPAN format allows IPv6 to be used over very low-power, low-
bandwidth wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery
over 6LoWPAN networks has several problems. Standard Neighbor
Discovery was not designed for wireless links, the standard IPv6 link
concept and heavy use of multicast makes it inefficient. This
document spefies a new mechanism allowing efficient Duplicate Address
Detection over entire 6LoWPAN networks. In addition it specifies
prefix and context dissemination for use with router advertisements,
allows for stateless address assignment, and the use of Neighbor
Discovery Proxy.
This document is an identical replacement of
draft-shelby-6lowpan-nd-01. This document was now submitted as a
6lowpan working group document.
"Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim,
Dominik Kaspar, Carles Gomez, Carsten Bormann, 18-Nov-08,
<draft-ietf-6lowpan-routing-requirements-00.txt>
This document provides the problem statement for 6LoWPAN routing. It
also defines the requirements for 6LoWPAN routing considering IEEE
802.15.4 specificities and the low-power characteristics of the
network and its devices.
IPv6 Maintenance (6man)
-----------------------
"Solution approaches for address-selection problems", Arifumi Matsumoto,
Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 18-Jun-08,
<draft-ietf-6man-addr-select-sol-01.txt>
In response to address selection problem statement and requirement
documents, this document describes approaches to solutions and
evaluates proposed solution mechanisms in line with requirements. It
also examines the applicability of each solution mechanism from the
viewpoint of practical application.
Matsumoto, et al.
Expires August 2, 2008
[page 1]
"IPv6 Node Requirements RFC 4294-bis", John Loughney, 3-Nov-08,
<draft-ietf-6man-node-req-bis-02.txt>
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.
"Reserved IPv6 Interface Identifiers", Suresh Krishnan, 14-Jul-08,
<draft-ietf-6man-reserved-iids-01.txt>
Interface Identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a
subnet. Several RFCs have specified interface identifiers or
identifier ranges that have a special meaning attached to them. An
IPv6 node autoconfiguring an interface identifier in these ranges
will encounter unexpected consequences. Since there is no
centralized repository for such reserved identifiers, this document
aims to create one.
"IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes",
Hemant Singh, Wes Beebee, Erik Nordmark, 6-Oct-08,
<draft-ietf-6man-ipv6-subnet-model-02.txt>
IPv6 specifies a model of a subnet that is different than the IPv4
subnet model. The subtlety of the differences has resulted in
incorrect implementations that do not interoperate. This document
spells out the most important difference; that an IPv6 address isn't
automatically associated with an IPv6 on-link prefix. This document
also invalidates (partially due to security concerns) a part of the
definition of on-link from [RFC4861].
"Handling of overlapping IPv6 fragments", Suresh Krishnan, 4-Nov-08,
<draft-ietf-6man-overlap-fragment-01.txt>
The fragmentation and reassembly algorithm specified in the base IPv6
specification allows fragments to overlap. This document
demonstrates the security issues with allowing overlapping fragments
and updates the IPv6 specification to explicitly forbid overlapping
fragments.
ADSL MIB (adslmib)
------------------
"Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2
(VDSL2)", Moti Morgenstern, Scott Baillie, Umberto Bonollo, 8-Jul-08,
<draft-ietf-adslmib-vdsl2-06.txt>
This document defines a Management Information Base (MIB) module for
use with network management protocols in the Internet community. In
particular, it describes objects used for managing parameters of the
"Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type,
which are also applicable for managing ADSL, ADSL2, and ADSL2+
interfaces.
"xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern,
Narendranath Nair, 1-Sep-08, <draft-ietf-adslmib-gbond-mib-02.txt>
This document defines Management Information Base (MIB) module for
use with network management protocols in TCP/IP-based internets.
This document proposes an extension to the Interfaces Group MIB with
a set of common objects for managing multi-pair bonded Digital
Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations
G.998.1, G.998.2 and G.998.3. The MIB modules specific to each
bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and
GBOND-TDIM-MIB respectively.
Access Node Control Protocol (ancp)
-----------------------------------
"Framework and Requirements for an Access Node Control Mechanism in Broadband
Multi-Service Networks", Sven Ooghe, Norbert Voigt, Michel Platnic, Thomas
Haag, Sanjay Wadhwa, 3-Nov-08, <draft-ietf-ancp-framework-07.txt>
The purpose of this document is to define a framework for an Access
Node Control Mechanism between a Network Access Server (NAS) and an
Access Node (e.g. a Digital Subscriber Line Access Multiplexer
(DSLAM)) in a multi-service reference architecture in order to
perform QoS-related, service-related and Subscriber-related
operations. The Access Node Control Mechanism will ensure that the
transmission of the information does not need to go through distinct
element managers but rather using a direct device-device
communication. This allows for performing access link related
operations within those network elements, while avoiding impact on
the existing OSS systems.
"Security Threats and Security Requirements for the Access Node Control
Protocol (ANCP)", Hassnaa Moustafa, Hannes Tschofenig, Stefaan De Cnodder,
7-Oct-08, <draft-ietf-ancp-security-threats-06.txt>
The Access Node Control Protocol (ANCP) aims to communicate QoS-
related, service-related and subscriber-related configurations and
operations between a Network Access Server (NAS) and an Access Node
(e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The
main goal of this protocol is to allow the NAS to configure, manage
and control access equipments including the ability for the access
nodes to report information to the NAS.
The present document investigates security threats that all ANCP
nodes could encounter. This document develops a threat model for
ANCP security aiming to decide which security functions are required.
Based on this, security requirements regarding the Access Node
Control Protocol are defined.
"Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay
Wadhwa, Jerome Moisand, Swami Subramanian, Thomas Haag, Norber Voigt, Roberta
Maglione, 3-Nov-08, <draft-ietf-ancp-protocol-04.txt>
This document describes proposed extensions to the GSMPv3 protocol to
allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g.
NAS). These proposed extensions are required to realize a protocol
for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].
The resulting protocol with the proposed extensions to GSMPv3
[RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
This document currently focuses on specific use cases of access node
control mechanism for topology discovery, line configuration, and OAM
as described in ANCP framework document [ANCP-FRAMEWORK]. It is
intended to be augmented by additional protocol specification for
future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP
protocol interactions.
"Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De
Cnodder, Moti Morgenstern, 24-Jun-08, <draft-ietf-ancp-mib-an-03.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing access nodes that are using the Access Node
Control Protocol (ANCP).
Ad-Hoc Network Autoconfiguration (autoconf)
-------------------------------------------
"Mobile Ad hoc Network Architecture", Ian Chakeres, Joseph Macker, Thomas
Clausen, 7-Nov-07, <draft-ietf-autoconf-manetarch-07.txt>
This document discusses Mobile Ad hoc NETworks (MANETs). It presents
the initial motivation for MANET and describes unaccustomed
characteristics and challenges. It also defines a MANET, other MANET
entities, and MANET architectural concepts.
Audio/Video Transport (avt)
---------------------------
"RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback",
Joerg Ott, 7-Jan-08, <draft-ietf-avt-rtcpssm-17.txt>
This document specifies an extension to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback to a multicast
sender. The proposed extension is useful for single-source multicast
sessions such as Source-Specific Multicast (SSM) communication where
the traditional model of many-to-many group communication is either
not available or not desired. In addition, it can be applied to any
group that might benefit from a sender-controlled summarized
reporting mechanism.
Ott et al.
Internet Draft - Expires July 2008
[page 1]
RTCP with Unicast Feedback
"RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family",
Jun Matsumoto, Mitsuyuki Hatanaka, 4-Sep-08,
<draft-ietf-avt-rtp-atrac-family-18.txt>
This document describes an RTP payload format for efficient and
flexible transporting of audio data encoded with the Adaptive
TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements
to the ATRAC family of codecs support high quality audio coding with
multiple channels. The RTP payload format as presented in this
document also includes support for data fragmentation, elementary
redundancy measures, and a variation on scalable streaming.
"Associating Time-codes with RTP streams", David Singer, 3-Nov-08,
<draft-ietf-avt-smpte-rtp-14.txt>
This document describes a mechanism for associating time-codes, as
defined by the Society of Motion Picture and Television Engineers
(SMPTE), with media streams, in a way that is independent of the RTP
payload format of the media stream itself.
"RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni
Even, 22-Aug-08, <draft-ietf-avt-rfc3047-bis-08.txt>
International Telecommunication Union (ITU-T) Recommendation G.722.1
is a wide-band audio codec. This document describes the payload
format for including G.722.1 generated bit streams within an RTP
packet. The document also describes the syntax and semantics of the
SDP parameters needed to support G.722.1 audio codec.
"RTP Payload Format for the Speex Codec", Greg Herlein, Jean-Marc Valin,
Alfred Heggestad, Aymeric Moizard, 16-Feb-08,
<draft-ietf-avt-rtp-speex-05.txt>
Speex is an open-source voice codec suitable for use in Voice over IP
(VoIP) type applications. This document describes the payload format
for Speex generated bit streams within an RTP packet. Also included
here are the necessary details for the use of Speex with the Session
Description Protocol (SDP).Editors Note
All references to RFC XXXX are to be replaced by references to the
RFC number of this memo, when published.
"How to Write an RTP Payload Format", Magnus Westerlund, 11-Sep-08,
<draft-ietf-avt-rtp-howto-05.txt>
This document contains information on how to best write an RTP
payload format. Reading tips, design practices, and practical tips
on how to quickly and with good results produce an RTP payload format
specification. A template is also included with instructions that
can be used when writing an RTP payload format.
"Transmission Time offsets in RTP streams", David Singer, HariKishan
Desineni, 11-Mar-08, <draft-ietf-avt-rtp-toffset-07.txt>
This document describes a method to inform RTP clients when RTP
packets are transmitted at a time other than their 'nominal'
transmission time. It also provides a mechanism to provide improved
inter-arrival jitter reports from the clients, that take into account
the reported transmission times.
"Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins,
Magnus Westerlund, 6-Aug-07, <draft-ietf-avt-rtp-and-rtcp-mux-07.txt>
This memo discusses issues that arise when multiplexing RTP data
packets and RTP control protocol (RTCP) packets on a single UDP port.
It updates RFC 3550 to describe when such multiplexing is, and is
not, appropriate, and explains how the Session Description Protocol
(SDP) can be used to signal multiplexed sessions.
"RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas
Schierl, Alex Eleftheriadis, 3-Nov-08, <draft-ietf-avt-rtp-svc-15.txt>
This memo describes an RTP payload format for Scalable Video Coding
(SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is
technically identical to Amendment 3 of ISO/IEC International
Standard 14496-10. The RTP payload format allows for packetization
of one or more Network Abstraction Layer (NAL) units in each RTP
packet payload, as well as fragmentation of a NAL unit in multiple
RTP packets. Furthermore, it supports transmission of an SVC stream
over a single as well as multiple RTP sessions. For single-session
transmission the packetization modes of [I-D.ietf-avt-rtp-
rfc3984bis] are used. For multi-session transmission four different
modes are defined in this memo. The modes differ depending on
whether the SVC data are allowed to be interleaved, i.e., to be
transmitted in an order different than the intended decoding order,
and they also differ in the mechanisms provided in order to recover
the correct decoding order of the NAL units across the multiple RTP
sessions. Specifically, decoding order recovery is performed using
either timestamp alignment or Cross-Session Decoding Order Numbers
(CS-DON), although in one of the modes both schemes are used in
order to allow receivers to use their preferred method. The multi-
session transmission modes use the packetization modes defined in
[I-D.ietf-avt-rtp-rfc3984bis] as each individual session still uses
a packetization mode defined in [I-D.ietf-avt-rtp-rfc3984bis]. The
packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are
slightly extended such that the three new NAL unit types defined in
this memo can be included in the RTP packet streams. The payload
format defines a new media subtype name "H264-SVC", but is still
backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base
layer, when encapsulated in its own RTP stream, must use the H.264
media subtype name ("H264") and the packetization method specified
in [I-D.ietf-avt-rtp-rfc3984bis]. The payload format has wide
applicability in videoconferencing, Internet video streaming, and
high bit-rate entertainment-quality video, among others.
Table of Contents
Status of this Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................2
"RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, Intellectual
Property, 6-Aug-08, <draft-ietf-avt-rfc4695-bis-04.txt>
This memo describes a Real-time Transport Protocol (RTP) payload
format for the MIDI (Musical Instrument Digital Interface) command
language. The format encodes all commands that may legally appear on
a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and content-
delivery applications (such as file streaming). The format may be
used over unicast and multicast UDP and TCP, and it defines tools for
graceful recovery from packet loss. Stream behavior, including the
MIDI rendering method, may be customized during session setup. The
format also serves as a mode for the mpeg4-generic format, to support
the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds
Level 2, and Structured Audio.
"RTP payload format for mU-law EMbedded Codec for Low-delay IP communication
(UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 25-Feb-08,
<draft-ietf-avt-rtp-uemclip-04.txt>
This document describes the RTP payload format of a mU-law EMbedded
Coder for Low-delay IP communication (UEMCLIP), an enhanced speech
codec of ITU-T G.711. The bitstream has a scalable structure with an
embedded u-law bitstream, also known as PCMU, thus providing a handy
transcoding operation between narrowband and wideband speech.
"Application Mechanism for maintaining alive the Network Address Translator
(NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud,
2-Oct-08, <draft-ietf-avt-app-rtp-keepalive-04.txt>
This document lists the different mechanisms that enable applications
using Real-time Transport Protocol (RTP) to maintain their RTP
Network Address Translator (NAT) mappings alive. It also makes a
recommendation for a preferred mechanism. This document is not
applicable to Interactive Connectivity Establishment (ICE) agents.
"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for
Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla,
29-Oct-08, <draft-ietf-avt-dtls-srtp-06.txt>
This document describes a Datagram Transport Layer Security (DTLS)
extension to establish keys for secure RTP (SRTP) and secure RTP
Control Protocol (SRTCP) flows. DTLS keying happens on the media
path, independent of any out-of-band signalling channel present.
"Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 7-Oct-08,
<draft-ietf-avt-forward-shifted-red-02.txt>
This document defines a simple enhancement to RFC 2198 to support RTP
sessions with forward-shifted redundant encodings, i.e., redundant
data sent before the corresponding primary data. Forward-shifted
redundancy can be used to conceal losses of a large number of
consecutive media frames (e.g., consecutive loss of seconds or even
tens of seconds of media).
"The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport
Protocol (SRTP)", Intellectual Property, 17-Nov-08,
<draft-ietf-avt-seed-srtp-07.txt>
This document describes the use of the SEED block cipher algorithm in
the Secure Real-time Transport Protocol (SRTP) for providing
confidentiality for the Real-time Transport Protocol (RTP) traffic
and for the control traffic for RTP, the Real-time Transport Control
Protocol (RTCP).
"Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar
Johansson, Magnus Westerlund, 18-Nov-08,
<draft-ietf-avt-rtcp-non-compound-08.txt>
This memo discusses benefits and issues that arise when allowing RTCP
packets to be transmitted with reduced size. The size can be reduced
if the rules on how to create compound packets outlined in RFC3550
are removed or changed. Based on that analysis this memo defines
certain changes to the rules to allow feedback messages to be sent as
reduced-size RTCP packets under certain conditions when using the RTP
AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711]
and [RFC4585].
"RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 22-May-08,
<draft-ietf-avt-rtp-h264-rcdo-01.txt>
This memo describes an RTP Payload format for the Reduced-Complexity
Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as
specified in H.241. RCDO reduces the decoding cost and resource
consumption of the video processing. The RTP Payload format is based
on the description in RFC 3984.
"G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud,
26-Sep-08, <draft-ietf-avt-rfc4749-dtx-update-02.txt>
This document updates the Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous
Transmission (DTX) support to the RFC 4749 specification, in a
backward-compatible way. An updated media type registration is
included for this payload format.
"RTP Payload Format for ITU-T Recommendation G.711.1", Aurelien Sollaud,
28-Apr-08, <draft-ietf-avt-rtp-g711wb-03.txt>
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.711.1 audio codec. Two media type registrations are also
included.
"Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin
Perkins, 7-Jul-08, <draft-ietf-avt-rtcp-guidelines-00.txt>
The RTP Control Protocol (RTCP) is used along with the Real-time
Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to
enable application adaptivity and monitoring, among other uses. The
basic reporting mechanisms offered by RTCP are generic, yet quite
powerful and suffice to cover a range of uses. This document
provides guidelines on extending RTCP if those basic mechanisms prove
insufficient.
"RTP Payload Format for Elementary Streams with MPEG Surround multi- channel
audio", Frans Bont, Stefan Doehla, Malte Schmidt, Ralph Sperschneider,
20-Oct-08, <draft-ietf-avt-rtp-mps-01.txt>
This memo describes extensions for the RTP payload format defined in
RFC3640 for the transport of MPEG Surround multi-channel audio.
Additional Media Type parameters are defined to signal backwards
compatible transmission inside an MPEG-4 audio elementary stream. In
addition a layered transmission scheme without using the MPEG-4
systems framework is presented to transport an MPEG Surround
elementary stream via RTP in parallel with an RTP stream containing
the downmixed audio data.
"RTP Payload format for G.719", Magnus Westerlund, Ingemar Johansson,
17-Nov-08, <draft-ietf-avt-rtp-g719-04.txt>
This document specifies the payload format for packetization of the
G.719 full-band codec encoded audio signals into the Real-time
Transport Protocol (RTP). The payload format supports transmission
of multiple channels, multiple frames per payload, and interleaving.
"Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu,
Michael Lague, 27-Oct-08, <draft-ietf-avt-post-repair-rtcp-xr-04.txt>
This document defines a new report block type within the framework of
RTP Control Protocol (RTCP) Extended Reports (XR). One of the
initial XR report block types is the Loss Run Length Encoding (RLE)
Report Block. This report conveys the information regarding the
individual Real-time Transport Protocol (RTP) packet receipt and loss
events experienced during the RTCP interval preceding the
transmission of the report. The new report, which is referred to as
the Post-repair Loss RLE Report, carries the information regarding
the remaining lost packets after all loss-repair methods are applied.
By comparing the RTP packet receipts/losses before and after the loss
repair is completed, one can determine the effectiveness of the loss-
repair methods in an aggregated fashion. This document also defines
the signaling of the Post-repair Loss RLE Report in the Session
Description Protocol (SDP).
"Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus
Westerlund, 4-Nov-08, <draft-ietf-avt-srtp-not-mandatory-01.txt>
This memo discusses the problem of securing real-time multimedia
sessions, and explains why the Real-time Transport Protocol (RTP)
does not mandate a single media security mechanism.
"RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen,
3-Nov-08, <draft-ietf-avt-rtp-rfc3984bis-01.txt>
This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere.
The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video
encoder, in each RTP payload. The payload format has wide
applicability, as it supports applications from simple low bit-rate
conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand.
This memo intends to obsolete RFC 3984. Changes from RFC 3984 are
summarized in section 17.
Issues on backward compatibility to RFC
3984 are discussed in section 16.
"RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang,
23-Oct-08, <draft-ietf-avt-rtp-g718-00.txt>
This document specifies the Real-Time Transport Protocol (RTP)
payload format for the Embedded Variable Bit-Rate (EV-VBR)
speech/audio codec, specified in ITU-T G.718. A media type
registration for this RTP payload format is also included.
"RTCP XR Report Block for Burst/Gap Loss metric Reporting", Geoff Hunt, Alan
Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-burst-gap-loss-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Burst and Gap Loss metrics for use in a range of RTP
applications.
"RTCP XR Report Block for Burst/Gap Discard metric Reporting", Geoff Hunt,
Alan Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-burst-gap-discard-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Burst and Gap Discard metrics for use in a range of RTP
applications.
"RTCP XR Report Block for Post-Repair Loss metric Reporting", Geoff Hunt,
Alan Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-postrepair-loss-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of a simple post-repair loss count metric for use in a
range of RTP applications. It complements the pre-repair loss count
metric "cumulative number of packets lost" provided by RFC3550.
"RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff
Hunt, Alan Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-pdv-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Packet Delay Variation metrics for a range of RTP
applications.
"RTCP XR Report Block for Measurement Identity", Geoff Hunt, Alan Clark,
27-Oct-08, <draft-ietf-avt-rtcp-xr-meas-identity-00.txt>
This document defines an RTCP XR Report Block carrying parameters
which identify a measurement, to which one or more other RTCP XR
Report Blocks may refer.
"RTCP XR Report Block for Loss Concealment metric Reporting", Geoff Hunt,
Alan Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-loss-conceal-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Loss Concealment metrics primarily for audio
applications of RTP.
"RTCP XR Report Block for Jitter Buffer Metric Reporting", Geoff Hunt, Alan
Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-jb-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Jitter Buffer metrics for a range of RTP applications.
"RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark,
27-Oct-08, <draft-ietf-avt-rtcp-xr-discard-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of a simple discard count metric for use in a range of RTP
applications.
"RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Alan Clark,
27-Oct-08, <draft-ietf-avt-rtcp-xr-delay-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Delay metrics for use in a range of RTP applications.
"RTCP XR Report Block for Concealed Seconds metric Reporting", Geoff Hunt,
Alan Clark, 27-Oct-08, <draft-ietf-avt-rtcp-xr-concsec-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of Concealed Seconds metrics primarily for audio
applications of RTP.
"RTCP XR Report Block for QoE Metrics Reporting", Alan Clark, Geoff Hunt,
27-Oct-08, <draft-ietf-avt-rtcp-xr-qoe-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of QoE metrics for use in voice, audio and video
services.
"RTCP XR Report Block for Signal Level Metrics Reporting", Alan Clark, Geoff
Hunt, 27-Oct-08, <draft-ietf-avt-rtcp-xr-siglevel-00.txt>
This document defines an RTCP XR Report Block that allows the
reporting of metrics related to signal levels for use in voice,
audio and video services.
Behavior Engineering for Hindrance Avoidance (behave)
-----------------------------------------------------
"Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip
Matthews, 29-Oct-08, <draft-ietf-behave-turn-11.txt>
If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using
the relay. TURN differs from some other relay control protocols in
that it allows a client to communicate with multiple peers using a
single relay address.
The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it can be also used without ICE.
"Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6
Transition", Gonzalo Camarillo, Oscar Novo, 29-Oct-08,
<draft-ietf-behave-turn-ipv6-05.txt>
This document defines the REQUESTED-ADDRESS-TYPE attribute for
Traversal Using Relays around NAT (TURN). The REQUESTED-ADDRESS-TYPE
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). Additionally, this
document also defines a new error response code with the value 440
(Address Family not Supported).
"NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, Bryan Ford,
Senthil Sivakumar, Saikat Guha, 22-Nov-08,
<draft-ietf-behave-nat-icmp-11.txt>
This document specifies the behavioral properties required of the
Network Address Translator (NAT) devices in conjunction with the
Internet Control Message Protocol (ICMP). The objective of this
memo is to make NAT devices more predictable and compatible with
diverse application protocols that traverse the devices. Companion
documents provide behavioral recommendations specific to TCP, UDP
and other protocols.
"NAT Behavior Discovery Using STUN", Derek MacDonald, Bruce Lowekamp,
3-Nov-08, <draft-ietf-behave-nat-behavior-discovery-05.txt>
This specification defines an experimental usage of the Simple
Traversal Underneath Network Address Translators (NAT) (STUN)
Protocol that discovers the presence and current behaviour of NATs
and firewalls between the STUN client and the STUN server.
"Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations",
Jonathan Rosenberg, Rohan Mahy, 4-Nov-08, <draft-ietf-behave-turn-tcp-01.txt>
This specification defines an extension of Traversal Using Relays
around NAT (TURN), a relay protocol for NAT traversal, to allows a
TURN client to request TCP allocations, and defines new requests and
indications for the TURN server to open and accept TCP connections
with the client's peers. TURN and this extension both purposefully
restrict the ways in which the relayed address can be used. In
particular, it prevents users from running general purpose servers
from ports obtained from the STUN server.
"Test vectors for STUN", Remi Denis-Courmont, 18-Nov-08,
<draft-ietf-behave-stun-test-vectors-04.txt>
The Session Traversal Utilities for NAT (STUN) protocol defines
several STUN attributes. The content of some of these --
FINGERPRINT, MESSAGE-INTEGRITY and XOR-MAPPED-ADDRESS -- involve
binary-logical operations (hashing, xor). This document provides
test vectors for those attributes.
"Network Address Translation (NAT) Behavioral Requirements for the Datagram
Congestion Control Protocol", Remi Denis-Courmont, 28-Oct-08,
<draft-ietf-behave-dccp-04.txt>
This document defines a set of requirements for NATs handling the
Datagram Congestion Control Protocol (DCCP). Those allow DCCP
applications, such as streaming applications to operate consistently.
These requirements are very similar to the TCP requirements for NATs
already published by the IETF. Developing NATs that meet this set of
requirements will greatly increase the likelihood that applications
using DCCP will function properly.
"Stream Control Transmission Protocol (SCTP) Network Address Translation",
Randall Stewart, Michael Tuexen, Irene Ruengeler, 22-Oct-08,
<draft-ietf-behave-sctpnat-00.txt>
Stream Control Transmission Protocol [RFC4960] provides a reliable
communications channel between two end-hosts in many ways similar to
TCP [RFC0793]. With the widespread deployment of Network Address
Translators (NAT), specialized code has been added to NAT for TCP
that allows multiple hosts to reside behind a NAT and yet use only a
single globally unique IPv4 address, even when two hosts (behind a
NAT) choose the same port numbers for their connection. This
additional code is sometimes classified as Network Address and Port
Translation or NAPT. To date, specialized code for SCTP has NOT yet
been added to most NATs so that only pure NAT is available. The end
result of this is that only one SCTP capable host can be behind a
NAT.
This document describes an SCTP specific variant of NAT which
provides similar features of NAPT in the single point and multi-point
traversal scenario.
Bidirectional Forwarding Detection (bfd)
----------------------------------------
"BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya,
31-Oct-08, <draft-ietf-bfd-mib-06.txt>
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.
"BFD For MPLS LSPs", Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George
Swallow, 20-Jun-08, <draft-ietf-bfd-mpls-07.txt>
One desirable application of Bi-directional Forwarding Detection
(BFD) is to detect a Multi Protocol Label Switched (MPLS) Label
Switched Path (LSP) data plane failure. LSP-Ping is an existing
mechanism for detecting MPLS data plane failures and for verifying
the MPLS LSP data plane against the control plane. BFD can be used
for the former, but not for the latter. However the control plane
processing required for BFD control packets is relatively smaller
than the processing required for LSP-Ping messages. A combination of
LSP-Ping and BFD can be used to provide faster data plane failure
detection and/or make it possible to provide such detection on a
greater number of LSPs. This document describes the applicability of
BFD in relation to LSP-Ping for this application. It also describes
procedures for using BFD in this environment.
"Bidirectional Forwarding Detection", Dave Katz, David Ward, 24-Mar-08,
<draft-ietf-bfd-base-08.txt>
This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols.
Comments on this draft should be directed to rtg-bfd@ietf.org.
"BFD for Multihop Paths", Dave Katz, David Ward, 16-Jan-08,
<draft-ietf-bfd-multihop-06.txt>
This document describes the use of the Bidirectional Forwarding
Detection protocol (BFD) over multihop paths, including
unidirectional links.
"BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 24-Mar-08,
<draft-ietf-bfd-v4v6-1hop-08.txt>
This document describes the use of the Bidirectional Forwarding
Detection protocol over IPv4 and IPv6 for single IP hops. Comments
on this draft should be directed to rtg-bfd@ietf.org.
"Generic Application of BFD", Dave Katz, David Ward, 16-Jan-08,
<draft-ietf-bfd-generic-04.txt>
This document describes the generic application of the Bidirectional
Forwarding Detection (BFD) protocol. Comments on this draft should
be directed to rtg-bfd@ietf.org.
Basic Level of Interoperability for SIP Services (bliss)
--------------------------------------------------------
"Basic Level of Interoperability for Session Initiation Protocol (SIP)
Services (BLISS) Problem Statement", Jonathan Rosenberg, 3-Nov-08,
<draft-ietf-bliss-problem-statement-03.txt>
The Session Initiation Protocol (SIP) has been designed as a general
purpose protocol for establishing and managing multimedia sessions.
It provides many core functions and extensions in support of features
such as transferring of calls, parking calls, and so on. However,
interoperability of more advanced features between different vendors
has been poor. This document describes the reason behind these
interoperability problems, and presents a framework for addressing
them.
"An Analysis of Automatic Call Handling Implementation Issues in the Session
Initiation Protocol (SIP)", John Elwell, 3-Nov-08,
<draft-ietf-bliss-ach-analysis-03.txt>
This discusses problems associated with automatic call handling (ACH)
when using the Session Initiation Protocol (SIP).
This work is being discussed on the bliss@ietf.org mailing list.
"Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin
Huelsemann, Denis Alexeitsev, 20-Jun-08,
<draft-ietf-bliss-call-completion-02.txt>
The features "call completion on busy subscriber" and "call
completion on no reply" allow the calling party of a failed call to
be notified when the called party becomes available to receive a
call. This document describes an architecture for implementing these
features in the Session Initiation Protocol: "Call completion"
implementations at the caller's and callee's endpoints cooperate to
place the caller's request for call completion into a queue at the
callee's endpoint, and, when a caller's request is ready to be
serviced, re-attempt the original, failed call.
"Shared Appearances of a Session Initiation Protocol (SIP) Address of Record
(AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan,
2-Nov-08, <draft-ietf-bliss-shared-appearances-01.txt>
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as Shared Appearances (SA) of an
Address of Record (AOR) since SIP does not have the concept of lines.
This feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. This document
lists requirements and compares implementation options for this
feature. Extensions to the SIP dialog event package are proposed.
Benchmarking Methodology (bmwg)
-------------------------------
"Benchmarking Methodology for Link-State IGP Data Plane Route Convergence",
Scott Poretsky, Brent Imhoff, Intellectual Property, 15-Oct-08,
<draft-ietf-bmwg-igp-dataplane-conv-meth-16.txt>
This document describes the methodology for benchmarking 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.
Link-State IGP Data Plane Route Convergence
"Terminology for Benchmarking Link-State IGP Data Plane Route Convergence",
Scott Poretsky, Brent Imhoff, Intellectual Property, 15-Oct-08,
<draft-ietf-bmwg-igp-dataplane-conv-term-16.txt>
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.
Link-State IGP Data Plane Route Convergence
"Considerations for Benchmarking Link-State IGP Data Plane Route
Convergence", Scott Poretsky, Intellectual Property, 15-Oct-08,
<draft-ietf-bmwg-igp-dataplane-conv-app-16.txt>
This document discusses considerations for benchmarking Interior
Gateway Protocol (IGP) Route Convergence for any link-state IGP, such
as Intermediate System-Intermediate System (ISIS) and Open-Shorted
Path first (OSPF).
A companion methodology document is to
be used for benchmarking IGP convergence time through externally
observable (black box) data plane measurements. A companion
"Benchmarking Terminology for Protection Performance", Scott Poretsky,
3-Nov-08, <draft-ietf-bmwg-protection-term-05.txt>
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, avoiding dependence on
specific sub-IP protection mechanisms. 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).
"Methodology for Benchmarking MPLS Protection Mechanisms", Rajiv Papneja,
Samir Vapiwala, Jay Karthik, Scott Poretsky, Shankar Rao, Jean-Louis Roux,
3-Nov-08, <draft-ietf-bmwg-protection-meth-04.txt>
Protection Mechanisms
This draft describes the methodology for benchmarking MPLS
Protection mechanisms for link and node protection as defined in
[MPLS-FRR-EXT]. This document provides test methodologies and test
bed setup for measuring failover times while considering all
dependencies that might impact faster recovery of real-time services
bound to MPLS based traffic engineered tunnels.
The terms used in the procedures included in this document are
defined in [TERM-ID].
"MPLS Forwarding Benchmarking Methodology", Aamer Akhter, Rajiv Asati,
3-Nov-08, <draft-ietf-bmwg-mpls-forwarding-meth-01.txt>
This document describes a methodology specific to the benchmarking
of MPLS forwarding devices, limited to various types of packet-
forwarding and delay measurements. It builds upon the tenets set
forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF
Benchmarking Methodology Working Group (BMWG) efforts. This
document seeks to extend these efforts to the MPLS paradigm.
Better-Than-Nothing Security (btns)
-----------------------------------
"IPsec Channels: Connection Latching", Nicolas Williams, 3-Nov-08,
<draft-ietf-btns-connection-latching-08.txt>
This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create "channels" by
latching "connections" (packet flows) to certain IPsec Security
Association (SA) parameters for the lifetime of the connections.
Connection latching is layered on top of IPsec and does not modify
the underlying IPsec architecture.
Connection latching can be used to protect applications against
accidentally exposing live packet flows to unintended peers, whether
as the result of a reconfiguration of IPsec or as the result of using
weak peer identity to peer address associations. Weak association of
peer ID and peer addresses is at the core of Better Than Nothing
Security (BTNS), thus connection latching can add a significant
measure of protection to BTNS IPsec nodes.
Finally, the availability of IPsec channels will make it possible to
use channel binding to IPsec channels.
"An abstract interface between applications and IPsec", Michael Richardson,
2-Nov-08, <draft-ietf-btns-abstract-api-02.txt>
This document explains in the abstract (no language bindings are
provided) how an application may learn that IPsec has been applied to
a conversation or specify that IPsec should be used. Though this is
useful in general it is particularly useful for applications that
wish to use BTNS (Better Than Nothing Security -- a mode of IPsec
keying), either in conjunction with channel binding or otherwise.
Calendaring and Scheduling Standards Simplification (calsify)
-------------------------------------------------------------
"iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov,
9-Jun-08, <draft-ietf-calsify-rfc2447bis-05.txt>
This document, iCalendar Message-Based Interoperability Protocol
(iMIP), specifies a binding from the iCalendar Transport-independent
Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
composed using constructs from RFC 2822, RFC 2045, RFC 2046,
RFC 2047 and RFC 2049.
This document is a product of Calendaring and Scheduling Standards
Simplification (calsify) working group. More information about the
IETF CALSIFY working group activities can be found on the IETF web
site at <http://www.ietf.org/html.charters/calsify-charter.html>.
The issue tracker for the Calsify WG is located at:
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify>
"iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus
Daboo, 3-Nov-08, <draft-ietf-calsify-2446bis-08.txt>
This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendaring systems. This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.
iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendaring systems. These scheduling methods permit two or more
calendaring systems to perform transactions such as publish,
schedule, reschedule, respond to scheduling requests, negotiation of
changes or cancel.
"Internet Calendaring and Scheduling Core Object Specification (iCalendar)",
Bernard Desruisseaux, 31-Oct-08, <draft-ietf-calsify-rfc2445bis-09.txt>
This document defines the iCalendar data format for representing and
exchanging calendaring and scheduling information such as events, to-
dos, journal entries and free/busy information, independent of any
particular calendar service or protocol.Editorial Note (To be removed by
RFC Editor prior to publication)
This document is a product of the Calendaring and Scheduling
Standards Simplification (Calsify) working group of the Internet
Engineering Task Force. Comments on this draft are welcomed, and
should be addressed to the ietf-calsify@osafoundation.org [1] mailing
list.
Control And Provisioning of Wireless Access Points (capwap)
-----------------------------------------------------------
"CAPWAP Protocol Specification", Michael Montemurro, Dorothy Stanley, Pat
Calhoun, 1-Nov-08, <draft-ietf-capwap-protocol-specification-15.txt>
This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol, meeting the objectives defined by
the CAPWAP working group in RFC 4564. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP
protocol, while separate binding extensions will enable its use with
additional wireless technologies.
"CAPWAP Protocol Binding for IEEE 802.11", Michael Montemurro, Dorothy
Stanley, Pat Calhoun, 1-Nov-08,
<draft-ietf-capwap-protocol-binding-ieee80211-12.txt>
Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility
management and radio management from the single access point to a
centralized controller.
This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network protocol.
"CAPWAP Threat Analysis for IEEE 802.11 Deployments", Scott Kelly, Charles
Clancy, 10-Sep-08, <draft-ietf-capwap-threat-analysis-04.txt>
Early Wireless Local Area Network (WLAN) deployments feature a "fat"
Access Point (AP) which serves as a stand-alone interface between the
wired and wireless network segments. However, this model raises
scaling, mobility, and manageability issues, and the Control and
Provisioning for Wireless Access Points (CAPWAP) protocol is meant to
address these issues. CAPWAP effectively splits the fat AP
functionality into two network elements, and the communication
channel between these components may traverse potentially hostile
hops. This document analyzes the security exposure resulting from
the introduction of CAPWAP, and summarizes the associated security
considerations for IEEE 802.11-based CAPWAP implementations and deployments.
"CAPWAP Access Controller DHCP Option", Pat Calhoun, 14-Oct-08,
<draft-ietf-capwap-dhc-ac-option-02.txt>
The Control And Provisioning of Wireless Access Points Protocol
allows a Wireless Termination Point to use DHCP to discover the
Access Controllers it is to connect to. This document describes the
DHCP options to be used by the CAPWAP protocol.
"CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong
Zhang, 1-Nov-08, <draft-ietf-capwap-base-mib-03.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular, it
describes managed objects for modeling the Control And Provisioning
of Wireless Access Points (CAPWAP) Protocol.
"CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, David Perkins, Chris
Elliott, Yong Zhang, 27-Oct-08, <draft-ietf-capwap-802dot11-mib-02.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular, it
describes managed objects for modeling the Control And Provisioning
of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless
binding.
Common Control and Measurement Plane (ccamp)
--------------------------------------------
"Procedures for Dynamically Signaled Hierarchical Label Switched Paths",
Kohei Shiomoto, Adrian Farrel, Richard Rabbat, Arthi Ayyangar, Zafar Ali,
17-Oct-08, <draft-ietf-ccamp-lsp-hierarchy-bis-05.txt>
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
for carrying traffic in those networks or in other (client) networks.
Protocol extensions already exist to facilitate the establishment of
an LSP as a numbered traffic engineering (TE) link within the same
instance of the routing as is used to advertise the links that it
traverses creating a Forwarding Adjacency (FA). This document extends
those mechanisms to support unnumbered FAs.
This document also defines how to indicate that an LSP should be
advertised as a link in another instance of the routing protocol (for
instance in a client network) and which instance to use. Furthermore,
mechanisms are defined to indicate when an LSP is to be used as a
component link of a TE link bundle and to identify the bundle.
"Ethernet Traffic Parameters", Dimitri Papadimitriou, Intellectual Property,
1-Nov-08, <draft-ietf-ccamp-ethernet-traffic-parameters-06.txt>
This document describes the Metro Ethernet Forum (MEF) - specific
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.
"OSPFv2 Routing Protocols Extensions for ASON Routing", Dimitri
Papadimitriou, Intellectual Property, 29-Oct-08,
<draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt>
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 to the OSPFv2
Link State Routing Protocol to meet the routing requirements for
routing in an ASON.
D.Papadimitriou et al. - Expires April 2009
[page 1]
draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt
October 2008
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.
"Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering
Networks", Zafar Ali, JP Vasseur, Anca Zamfir, Jonathan Newton, 29-Oct-08,
<draft-ietf-ccamp-mpls-graceful-shutdown-08.txt>
MPLS-TE Graceful Shutdown is a method for explicitly notifying
the nodes in a Traffic Engineering (TE) enabled network that the
TE capability on a link or on an entire Label Switching Router
(LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored toward addressing planned outage in the
network.
This document provides requirements and protocol mechanisms to
reduce/eliminate traffic disruption in the event of a planned
shutdown of a network resource. These operations are equally
applicable to both MPLS and its Generalized MPLS (GMPLS)
extensions.
Ali et al.
Expires April 2009
[page 1]
draft-ietf-ccamp-mpls-graceful-shutdown-08.txt
"Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment
Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg
Bernstein, 18-Nov-08, <draft-ietf-ccamp-gmpls-vcat-lcas-06.txt>
This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to Optical Transport Network
(OTN), Synchronous Optical Network (SONET), Synchronous Digital
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.
"Traffic Engineering Database Management Information Base in support of
MPLS-TE/GMPLS", Thomas Nadeau, 4-Aug-08,
<draft-ietf-ccamp-gmpls-ted-mib-04.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-pc-and-sc-reqs-06.txt", Diego Caviglia, Dino Bramanti, Dan
Li, Dave McDysan, 15-Sep-08, <draft-ietf-ccamp-pc-and-sc-reqs-06.txt>
From a Carrier perspective, the possibility of turning a Permanent
Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic being carried
over it, is a valuable option. In other terms, such operation can be
seen as a way of transferring the ownership and control of an
existing and in-use Data Plane connection between the Management
Plane and the Control Plane, leaving its Data Plane state untouched.
This memo sets out the requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.
"OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang,
27-Jul-08, <draft-ietf-ccamp-ospf-interas-te-extension-06.txt>
This document describes extensions to the OSPF version 2 and 3
protocols to support Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
for the flooding of TE information about inter-AS links which can be
used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
"Description of the RSVP-TE Graceful Restart Procedures", Dan Li, 19-May-08,
<draft-ietf-ccamp-gr-description-03.txt>
The Hello message for the Resource Reservation Protocol (RSVP) has
been defined to establish and maintain basic signaling node
adjacencies for Label Switching Routers (LSRs) participating in a
Multiprotocol Label Switching (MPLS) traffic engineered (TE)
network. The Hello message has been extended for use in Generalized
MPLS (GMPLS) network for state recovery of control channel or nodal
faults.
"Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou,
Martin Vigoureux, Kohei Shiomoto, Deborah Brungard, Jean-Louis Roux, Eiji
Oki, Ichiro Inoue, Emmanuel Dotaro, Gert Grammel, 3-Nov-08,
<draft-ietf-ccamp-gmpls-mln-extensions-03.txt>
There are requirements for the support of networks comprising LSRs
with different data plane switching layers controlled by a single
Generalized Multi Protocol Label Switching (GMPLS) control plane
instance, referred to as GMPLS Multi-Layer Networks/Multi-Region
Networks (MLN/MRN).
This document defines extensions to GMPLS routing and signaling
protocols so as to support the operation of GMPLS Multi-Layer/Multi-
Region Networks. It covers the elements of a single GMPLS control
plane instance controlling multiple LSP regions or layers within a
single TE domain.
"ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang,
4-Sep-08, <draft-ietf-ccamp-isis-interas-te-extension-04.txt>
This document describes extensions to the ISIS (ISIS) protocol to
support Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems
(ASes). It defines ISIS-TE extensions for the flooding of TE
information about inter-AS links which can be used to perform inter-
AS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
"GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou
Berger, Loa Andersson, 27-Oct-08,
<draft-ietf-ccamp-gmpls-ethernet-arch-03.txt>
There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as SONET/SDH TDM and ATM. This document defines an
architecture and framework for a GMPLS based control plane for
Ethernet in this "transport network" capacity. GMPLS has already been
specified for similar technologies. Some additional extensions to the
GMPLS control plane are needed and this document provides a framework
for these extensions.Contents
"Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label
Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, Dimitri
Papadimitriou, JP Vasseur, Arthi Ayyangar, 27-May-08,
<draft-ietf-ccamp-rfc4420bis-03.txt>
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions. This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to
indicate options and attributes of the LSP. That Flags field has
eight bits allowing for eight options to be set. Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits.
This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements. Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.
"GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", Lou
Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 17-Nov-08,
<draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt>
This document defines a method for the support of GMPLS Asymmetric
Bandwidth Bidirectional Label Switched Paths (LSPs). The presented
approach is applicable to any switching technology and builds on the
original RSVP model for the transport of traffic related parameters.
The procedures described in this document are experimental.
"Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu
Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, 24-Jun-08,
<draft-ietf-ccamp-lsp-dppm-02.txt>
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission
network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop
Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. Dynamic provisioning ability of these
physically diverse devices differs from each other drastically. At
the same time, the need for Dynamicly provisioned connections is
increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the Dynamic LSP setup/release performance. These
metrics can depict the features of GMPLS networks in LSP dynamic
provisioning. They can also be used in operational networks for
carriers to monitor the control plane performance in realtime.
"Data Channel Status Confirmation Extensions for the Link Management
Protocol", Dan Li, Huiying Xu, Fatai Zhang, Snigdho Bardalai, Julien Meuric,
Diego Caviglia, 2-Nov-08,
<draft-ietf-ccamp-confirm-data-channel-status-02.txt>
This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in
the location of stranded resources by allowing adjacent LSRs to
confirm data channel statuses, and provides triggers for notifying
the management plane if any discrepancies are found.
"RSVP Extensions for Path Key Support", Richard Bradford, JP Vasseur, Adrian
Farrel, 1-Nov-08, <draft-ietf-ccamp-path-key-ero-02.txt>
The paths taken by Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
Paths (LSPs) may be computed by Path Computation Elements (PCEs).
Where the TE LSP crosses multiple domains, such as Autonomous Systems
(ASes), the path may be computed by multiple PCEs that cooperate,
with each responsible for computing a segment of the path.
To preserve confidentiality of topology within each AS, the PCEs
support a mechanism to hide the contents of a segment of a path (such
as the segment of the path that traverses an AS), called the
Confidential Path Segment (CPS), by encoding the contents as a Path
Key Subobject (PKS) and embedding this subobject within the result of
its path computation.
This document describes how to carry Path Key Subobjects in the
Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs)
and Record Route Object (RROs) so as to facilitate confidentiality in
the signaling of inter-domain TE LSPs.
"draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt", Diego Caviglia, Daniele
Ceccarelli, Dino Bramanti, Dan Li, Snigdho Bardalai, 31-Oct-08,
<draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt>
We would like to dedicate this work to our friend and colleague Dino
Bramanti, who passed away at the early age of 38. Dino has been
involved in this work since its beginning.
In a transport network scenario, where Data Plane connections
controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may
independently coexist, the ability of transforming an existing PC
into a SPC and vice versa - without actually affecting Data Plane
traffic being carried over it - is a requirement. See draft
"draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor
extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872]
signaling protocol, within GMPLS architecture, to enable such
connection ownership transfer and describes the proposed procedures.
Failure conductions and subsequent roll back are also illustrated
taking into account that an handover failure must not impact the
already established data plane connections.
"GMPLS control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah,
Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou
Berger, 13-Jul-08, <draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt>
This specification is complementary to the GMPLS controlled Ethernet
architecture document [ARCH] and describes the technology specific
aspects of GMPLS control for Provider Backbone Bridging Traffic
Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions
and mechanisms are described to establish Ethernet PBB-TE point to
point (P2P) and point to multipoint (P2MP) connections. This document
supports, but does not modify, the standard IEEE data plane.
"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
Ethernet Service Switching", Lou Berger, Don Fedyk, 8-Aug-08,
<draft-ietf-ccamp-gmpls-ether-svcs-02.txt>
This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS). This document supports the types of switching implied by
the Ethernet services that have been defined in the context of the
Metro Ethernet Forum (MEF) and International Telecommunication Union
(ITU) G.8011. Specifically, switching in support of Ethernet private
line service and Ethernet virtual private line service. Support for
MEF and ITU defined parameters are also covered. Some of the
extensions defined in this document are generic in nature and not
specific to Ethernet.
"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
User-Network Interface (UNI)", Lou Berger, Don Fedyk, 8-Aug-08,
<draft-ietf-ccamp-gmpls-mef-uni-01.txt>
This document describes a method for controlling two specific types
of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI). This document
supports the types of switching required to implied by the Ethernet
services that have been defined in the context of the Metro Ethernet
Forum (MEF) and International Telecommunication Union (ITU) G.8011.
This document is the UNI companion to "Generalized MPLS (GMPLS)
Support For Metro Ethernet Forum and G.8011 Ethernet Service
Switching". This document does not define or limit the underlying
intra-domain or Internal NNI (I-NNI) technology used to support the
UNI.
"Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks
(WSON)", Greg Bernstein, 31-Oct-08,
<draft-ietf-ccamp-wavelength-switched-framework-01.txt>
This memo provides a framework for applying Generalized Multi-
Protocol Label Switching (GMPLS) and the Path Computation Element
(PCE) architecture to the control of wavelength switched optical
networks (WSON). In particular we provide control plane models for
key wavelength switched optical network subsystems and processes. The
subsystems include wavelength division multiplexed links, tunable
laser transmitters, reconfigurable optical add/drop multiplexers
(ROADM) and wavelength converters.
Lightpath provisioning, in general, requires the routing and
wavelength assignment (RWA) process. This process is reviewed and the
information requirements, both static and dynamic for this process
are presented, along with alternative implementation scenarios that
could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols.
This memo does NOT address optical impairments in any depth and
focuses on topological elements and path selection constraints that
are common across different WSON environments. It is expected that a
variety of different techniques will be applied to optical
impairments depending on the type of WSON, such as access, metro or
long haul.
"Generalized Labels for G.694 Lambda-Switching Capable Label Switching
Routers", Tomohiro Otani, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia,
14-Jul-08, <draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt>
Technology in the optical domain is constantly evolving and as a
consequence new equipment providing lambda switching capability has
been developed and is currently being deployed. However, RFC 3471 has
defined that a wavelength label (section 3.2.1.1) "only has
significance between two neighbors" and global wavelength continuity
is not considered. In order to achieve interoperability in a network
composed of next generation lambda switch-capable equipment, this
document defines a standard lambda label format, being compliant with
ITU-T G.694. Moreover some consideration on how to ensure lambda
continuity with RSVP-TE is provided. This document is a companion to
the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It
defines the label format when Lambda Switching is requested in an all
optical network.
"Service Provider Requirements for Ethernet control with GMPLS", Wataru
Imajuku, Yoshiaki Sone, Muneyoshi Suzuki, Kazuhiro Matsuda, Nabil Bitar,
11-Jun-08, <draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt>
Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
Ethernet switches supporting Provider Backbone Bridge Traffic
Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label
switch network not only automates creation of Ethernet Label Switched
Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
Mechanisms such as protection and restoration of an Eth-LSP. This
document describes the requirements for the set of solutions of GMPLS
controlled Ethernet label switch networks.
"Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel
Set Label Extensions", Lou Berger, Don Fedyk, 8-Aug-08,
<draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt>
This document describes two technology independent extensions to
Generalized Multi-Protocol Label Switching. The first extension
defines the new switching type Data Channel Switching Capable. Data
Channel Switching Capable interfaces are able to support switching of
the whole digital channel presented on single channel interfaces.
The second extension defines a new type of generalized label and
updates related objects. The new label is called the Generalized
Channel_Set Label and allows more than one data plane label to be
controlled as part of an LSP.
"Routing and Wavelength Assignment Information Model for Wavelength Switched
Optical Networks", Greg Bernstein, 3-Nov-08,
<draft-ietf-ccamp-rwa-info-01.txt>
This document provides a model of information needed by the routing
and wavelength assignment (RWA) process in wavelength switched
optical networks (WSONs). The purpose of the information described
in this model is to facilitate constrained lightpath computation in
WSONs, particularly in cases where there are no or a limited number
of wavelength converters available. This model currently does not
include optical impairments.
Cga & Send maIntenance (csi)
----------------------------
"SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang,
3-Nov-08, <draft-ietf-csi-hash-threat-01.txt>
This document analysis the use of hashes in SeND, possible threats
and the impact of recent attacks on hash functions used by SeND.
Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc3280] and does not provide
support for the hash algorithm agility. The purpose of the document
is to provide analysis of possible hash threats and to decide how to
encode the hash agility support in SeND.
"Securing Neighbor Discovery Proxy Problem Statement", Greg Daley,
Jean-Michel Combes, Suresh Krishnan, 20-Oct-08,
<draft-ietf-csi-sndp-prob-00.txt>
Neighbor Discovery Proxy is used to provide an address presence on a
link from nodes which are no themselves present. It allows a node to
receive packets directed at its address by allowing another device to
Neighbor advertise on its behalf.
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols
to provide reachability from nodes on the home network when a Mobile
Node is not at home, by allowing the Home Agent to act as proxy. It
is also used as a mechanism to allow a global prefix to span multiple
links, where proxies act as relays for Neighbor discovery messages.
Neighbor Discovery Proxy currently cannot be secured using SEND.
Today, SEND assumes that a node advertising an address is the address
owner and in possession of appropriate public and private keys for
that node. This document describes how existing practice for proxy
Neighbor Discovery relates to Secured Neighbor Discovery.
"Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco
Bonola, 4-Nov-08, <draft-ietf-csi-proxy-send-00.txt>
Secure Neighbor Discovery (SEND) specifies a method for securing
Neighbor Discovery (ND) signaling against specific threats. As
specified today, SEND assumes that the node advertising an address is
the owner of the address and is in possession of the private key used
to generate the digital signature on the message. This means that
the Proxy ND signaling initiated by nodes that do not possess
knowledge of the address owner's private key cannot be secured using
SEND. This document extends the current SEND specification with
support for Proxy ND, the Secure Proxy ND Support for SEND.
Datagram Congestion Control Protocol (dccp)
-------------------------------------------
"Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally
Floyd, Arjuna Sathiaseelan, Intellectual Property, 14-Jul-08,
<draft-ietf-dccp-tfrc-faster-restart-06.txt,.pdf>
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
for unicast flows operating in a best-effort Internet environment.
This document introduces Faster Restart, an optional mechanism for
safely improving the behavior of interactive flows that use TFRC.
Faster Restart is proposed for use with TFRC and with TFRC-SP, the
Small Packet variant of TFRC. We present Faster Restart in general
terms as a congestion control mechanism, and further discuss Faster
Restart for Datagram Congestion Control Protocol (DCCP) Congestion
Control IDs 3 and 4.
"RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins,
22-Jun-07, <draft-ietf-dccp-rtp-07.txt>
The Real-time Transport Protocol (RTP) is a widely used transport for
real-time multimedia on IP networks. The Datagram Congestion Control
Protocol (DCCP) is a newly defined transport protocol that provides
desirable services for real-time applications. This memo specifies a
mapping of RTP onto DCCP, along with associated signalling, such that
real-time applications can make use of the services provided by DCCP.
"The DCCP Service Code", Gorry Fairhurst, 29-Sep-08,
<draft-ietf-dccp-serv-codes-08.txt>
This document describes the usage of Service Codes by the Datagram
Congestion Control Protocol, RFC 4340. It motivates the setting of a
Service Code by applications. Service Codes provide a method to
identify the intended service/application to process a DCCP
connection request. This provides improved flexibility in the use and
assignment of port numbers for connection multiplexing. The use of a
DCCP Service Code can also enable more explicit coordination of
services with middleboxes (e.g. network address translators and
firewalls). This document updates the specification provided in RFC
4340.
"DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal",
Gorry Fairhurst, 8-Oct-08, <draft-ietf-dccp-simul-open-05.txt>
This document specifies an update to the Datagram Congestion Control
Protocol (DCCP), a connection-oriented and datagram-based transport
protocol. The update adds support for the DCCP-Listen packet. This
assists DCCP applications to communicate through middleboxes (e.g. a
DCCP server behind a firewall, or a Network Address Port Translator),
where peering endpoints need to initiate communication in a near-
simultaneous manner to establish necessary middlebox state.
"Quick-Start for Datagram Congestion Control Protocol (DCCP)", Gorry
Fairhurst, 5-Sep-08, <draft-ietf-dccp-quickstart-01.txt>
This document specifies the use of the Quick-Start mechanism by the
Datagram Congestion Control Protocol (DCCP). DCCP is a transport
protocol that allows the transmission of congestion-controlled,
unreliable datagrams. DCCP is intended for applications such as
streaming media, Internet telephony, and on-line games. In DCCP, an
application has a choice of congestion control mechanisms, each
specified by a Congestion Control Identifier (CCID). This document
specifies general procedures applicable to all DCCP CCIDs and
specific procedures for the use of Quick-Start with DCCP CCID-2 and
CCID-3. Quick-Start enables a DCCP sender to cooperate with any
Quick-Start routers along the end-to-end path to determine an
allowed sending rate at the start and, at times, in the middle of a
DCCP connection (e.g., after an idle or application-limited period).
The present specification is provided for use in controlled
environments, and not as a mechanism that would be intended or
appropriate for ubiquitous deployment in the global Internet.
Dynamic Host Configuration (dhc)
--------------------------------
"Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear,
Richard Johnson, Mark Stapp, Jay Kumarasamy, 8-Jul-08,
<draft-ietf-dhc-vpn-option-09.txt>
This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
and DHCPv6, and a DHCPv4 relay-agent-information sub-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].
"Subnet Allocation Option", Richard Johnson, 8-Jul-08,
<draft-ietf-dhc-subnet-alloc-07.txt>
This document defines a new DHCP option which is passed between the
DHCP Client and the DHCP Server to request dynamic allocation of a
subnet, give specifications of subnet(s) allocated, and report usage
statistics. This memo documents the current usage of the option in
agreement with [RFC3942], which declares that any pre-existing usages
of option numbers in the range 128 - 223 should be documented and the
working group will try to officially assign those numbers to those
options.
"Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms,
17-Nov-08, <draft-ietf-dhc-dhcpv6-reconfigure-rebind-06.txt>
This document updates RFC 3315 to allow the Rebind message type to
appear in the Reconfigure Message option of a Reconfigure message,
which extends the Reconfigure message to allow a DHCPv6 server to
cause a DHCPv6 client to send a Rebind message. The document also
clarifies how a DHCPv6 client responds to a received Reconfigure
message.
"Guidelines for Creating New DHCP Options", David Hankins, 14-Oct-08,
<draft-ietf-dhc-option-guidelines-03.txt>
This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily
adoptable.
"Container Option for Server Configuration", Ralph Droms, 17-Nov-08,
<draft-ietf-dhc-container-opt-03.txt>
In some DHCP service deployments, it is desirable for a DHCP server
in one administrative domain to pass configuration options to a DHCP
server in a different administrative domain. This DHCP option
carries a set of DHCP options that can be used by another DHCP
server.
"Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 1-Oct-08,
<draft-ietf-dhc-l2ra-02.txt>
In some networks, DHCP servers rely on Relay Agent Information option
appended by Relay Agents for IP address and other parameter
assignment policies. This works fine when end hosts are directly
connected to Relay Agents. In some network configurations, one or
more Layer 2 devices may reside between DHCP clients and Relay agent.
In these network scenarios, it is difficult to use the Relay Agent
Information option for IP address and other parameter assignment
policies effectively. So there is a need for the device that is
closest to the end hosts to append Relay Agent Information option in
DHCP messages. These devices are typically known as Layer 2 Relay
Agents.
This document aims to describe the network scenarios where Layer 2
Relay Agent is in use and also how it handles DHCP messages.
"DHCPv6 Bulk Leasequery", Mark Stapp, 16-Oct-08,
<draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt>
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv6 binding data via TCP.
"Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund
Kamath, Stefaan De Cnodder, 14-Jun-08,
<draft-ietf-dhc-l2ra-extensions-00.txt>
As per industry trends, Access Networks have been migrating from
traditional ATM based networks to Ethernet networks. In Ethernet
based access networks, Access Concentrators are typically configured
to act as a transparent bridge in Layer 2 mode. These Access
Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality
does not provide means to avoid flooding of DHCP messages and also needs
to be extended to support DHCP LeaseQuery This draft discusses these issues
and provides solutions for the same.
"The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 30-Sep-08,
<draft-ietf-dhc-relay-id-suboption-04.txt>
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.
"DHCPv6 option for network boot", Thomas Huth, Jens Freimann, 18-Nov-08,
<draft-ietf-dhc-dhcpv6-opt-netboot-02.txt>
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
framework for passing configuration information to nodes on a
network. This document describes a new option for DHCPv6 to convey
information, required for network booting, to the nodes.
"DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V.
Ramakrishna Rao, Bharat Joshi, 20-Oct-08,
<draft-ietf-dhc-leasequery-by-remote-id-00.txt>
Some Relay Agents extract lease information from the DHCP message
exchanged between the client and DHCP server. This lease information
is used by relay agents for various purposes like antispoofing,
prevention of flooding. RFC 4388 defines a mechanism for relay
agents to retrieve the lease information from the DHCP server as and
when this information is lost. Existing leasequery mechanism is data
driven which means that a relay agent can initiate the leasequery
only when it starts receiving data from/to the clients. In certain
scenarios, this model is not scalable. This document first looks at
issues in existing mechanism and then proposes a new query type,
query by remote ID, to address these issues.
Diameter Maintenance and Extensions (dime)
------------------------------------------
"The Diameter API", Pat Calhoun, David Frascone, 28-Jul-08,
<draft-ietf-dime-diameter-api-07.txt>
The Diameter authentication, authorization, and accounting (AAA)
protocol provides support for peering AAA transactions across the
Internet. This document describes an API for the Diameter protocol.
The API is defined for the C language. The intent of the API is to
foster source code portability across multiple programming platforms.
"Diameter Mobile IPv6: Support for Home Agent to Diameter Server
Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo
Giaretta, Madjid Nakhjiri, 27-Oct-08, <draft-ietf-dime-mip6-split-13.txt>
Mobile IPv6 deployments may want to bootstrap their operations
dynamically based on an interaction between the Home Agent and the
Diameter server of the Mobile Service Provider (MSP). This document
specifies the interaction between a Mobile IP Home Agent and that
Diameter server.
Several different mechanisms for authenticating a Mobile Node are
supported. The usage of the Internet Key Exchange v2 (IKEv2)
protocol allows different mechanisms, such as the Extensible
Authentication Protocol (EAP), certificates and pre-shared secrets to
be used. Furthermore, another method makes use of the Mobile IPv6
Authentication Protocol. In addition to authentication and
authorization, the configuration of Mobile IPv6 specific parameters
and accounting is specified in this document.
"Diameter Mobile IPv6: Support for Network Access Server to Diameter Server
Interaction", Jouni Korhonen, Julien Bournelle, Hannes Tschofenig, Charles
Perkins, Kuntal Chowdhury, 19-Nov-08,
<draft-ietf-dime-mip6-integrated-11.txt>
A Mobile IPv6 node requires a home agent address, a home address, and
a security association with its home agent before it can start
utilizing Mobile IPv6. RFC 3775 requires that some or all of these
parameters are statically configured. Mobile IPv6 bootstrapping work
aims to make this information dynamically available to the Mobile
Node. An important aspect of the Mobile IPv6 bootstrapping solution
is to support interworking with existing authentication,
authorization and accounting infrastructure. This document describes
MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to
home Authentication, Authorization and Accounting server (HAAA)
interface.
"Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen
Zorn, 2-Nov-08, <draft-ietf-dime-rfc3588bis-13.txt>
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.
"Diameter Quality of Service Application", Dong Sun, Peter McCann, Hannes
Tschofenig, Tina Tsou, Avri Doria, Glen Zorn, 13-Jul-08,
<draft-ietf-dime-diameter-qos-06.txt>
This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) application. The Diameter QoS
application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two
modes of operation -- Pull and Push -- are defined.
"Diameter Applications Design Guidelines", Victor Fajardo, Tolga Asveren,
Hannes Tschofenig, Glenn McGregor, John Loughney, 13-Jul-08,
<draft-ietf-dime-app-design-guide-07.txt>
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.
"Quality of Service Parameters for Usage with the AAA Framework", Jouni
Korhonen, Hannes Tschofenig, 3-Nov-08,
<draft-ietf-dime-qos-parameters-07.txt>
This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and
Diameter.
The payloads used to carry these QoS parameters are opaque for the
AAA client and the AAA server itself and interpreted by the
respective Resource Management Function.
"Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes
Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 28-Oct-08,
<draft-ietf-dime-qos-attributes-08.txt>
This document extends the IPFilterRule AVP functionality of the
Diameter Base protocol and the functionality of the QoS-Filter-Rule
AVP defined in RFC 4005. The ability to convey Quality of Service
information using the AVPs defined in this document is available to
existing and future Diameter applications where permitted by the
command ABNF.
Domain Keys Identified Mail (dkim)
----------------------------------
"DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, Dave
Crocker, Phillip Hallam-Baker, 11-Jul-08,
<draft-ietf-dkim-overview-10.txt,.pdf>
This document provides an overview of the DomainKeys Identified Mail
(DKIM) service and describes how it can fit into a messaging service.
It also describes how DKIM relates to other IETF message signature
technologies. It is intended for those who are adopting, developing,
or deploying DKIM. DKIM allows an organization to take
responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public-
key cryptography, using the domain name service as its key server
technology [RFC4871]. This permits verification of a responsible
organization, as well as the integrity of the message contents. DKIM
will also provide a mechanism that permits potential email signers to
publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing.
"DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Eric Allman,
Jim Fenton, Mark Delany, John Levine, 19-Sep-08, <draft-ietf-dkim-ssp-06.txt>
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages. This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address. It defines a
record that can advertise whether a domain signs its outgoing mail,
and how other hosts can access that record.
"DomainKeys Identified Mail (DKIM) Development, Deployment and Operations",
Tony Hansen, Phillip Hallam-Baker, Dave Crocker, Ellen Siegel, 3-Nov-08,
<draft-ietf-dkim-deployment-02.txt>
DomainKeys Identified Mail (DKIM) allows an organization to take
responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public
key cryptography, using the domain name service as its key server
technology [RFC4871]. This permits verification of a responsible
organization, as well as the integrity of the message contents. DKIM
will also provide a mechanism that permits potential email signers to
publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing. This document provides
implementation, deployment, operational and migration considerations
for DKIM.
Detecting Network Attachment (dna)
----------------------------------
"Design document for Detecting Network Attachment in IPv6 Networks (DNAv6
Design)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland,
JinHyeock Choi, Greg Daley, Nicolas Montavont, 11-Jul-08,
<draft-ietf-dna-protocol-08.txt>
Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to
query routers on the link to identify the link (Link Identification)
and a method for the routers on the link to consistently respond to
such a query with minimal delay (Fast RA). Solving the link
identification based strictly on RFC 2461 is difficult because of the
flexibility offered to routers in terms of prefixes advertised in a
router advertisement (RA) message. Similarly, the random delay in
responding to router solicitation messages imposed by RFC 2461 makes
it difficult to receive an RA quickly. In this memo, a mechanism
that was developed for detection of network attachement is documented
for future reference. This memo is an informational document and
thus does not define a new standard. The mechanism proposed in this
informational RFC requires the hosts to monitor all the prefixes
advertised on the link and use it for link identification in the
presence of non-DNAv6 routers is presented. A more efficient link-
identification mechanism requiring the DNAv6 routers to monitor the
link for advertised prefixes to assist the hosts in link
identification combined with a fast router advertisement mechanism
that selects the order of response for the router deterministically
is also presented.
"Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery",
Greg Daley, Erik Nordmark, 13-Jul-08, <draft-ietf-dna-tentative-01.txt>
The proposed IPv6 Duplicate Address Detection (DAD) Optimization
"Optimistic DAD" defines a set of recoverable procedures which allow
a node to make use of an address before DAD completes. Essentially,
Optimistic DAD forbids usage of certain Neighbour Discovery options
which could pollute active neighbour cache entries, while an address
is tentative.
This document defines a new option and procedures to replace cache
polluting options, in a way which is useful to tentative nodes.
These procedures are designed to be to backward compatible with
existing devices which support IPv6 Neighbour Discovery.
"Simple procedures for Detecting Network Attachment in IPv6", Suresh
Krishnan, Greg Daley, 3-Nov-08, <draft-ietf-dna-simple-05.txt>
Detecting Network Attachment allows hosts to assess if its existing
addressing or routing configuration is valid for a newly connected
network.
This document provides simple procedures for detecting network
attachment in IPv6 hosts, and procedures for routers to support such
services.
DNS Extensions (dnsext)
-----------------------
"DNS Zone Transfer Protocol (AXFR)", Edward Lewis, 14-Jul-08,
<draft-ietf-dnsext-axfr-clarify-09.txt>
The Domain Name System standard mechanisms for maintaining coherent
servers for a zone consist of three elements. One mechanism is the
Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035.
The definition of AXFR, has proven insufficient in detail, forcing
implementations intended to be compliant to make assumptions, impeding
interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new
definition of the AXFR, new in the sense that is it recording an
accurate definition of an interoperable AXFR mechanism.
"Evaluating DNSSEC Transition Mechanisms", Roy Arends, Peter Koch, Jakob
Schlyter, 14-Jul-08, <draft-ietf-dnsext-dnssec-trans-06.txt>
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
way forward. It is a snapshot of the DNSEXT working group discussion
of June 2004.
"Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David
Blacka, 14-Jul-08, <draft-ietf-dnsext-dnssec-bis-updates-07.txt>
This document is a collection of minor technical clarifications to
the DNSSECbis document set. It is meant to serve as a resource to
implementors as well as an interim repository of DNSSECbis errata.
"Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd,
14-Jul-08, <draft-ietf-dnsext-2929bis-07.txt>
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
"Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for
DNSSEC", Jelte Jansen, 23-Oct-08, <draft-ietf-dnsext-dnssec-rsasha256-06.txt>
This document describes how to produce RSA/SHA-256 and RSA/SHA-512
DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
"Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards,
16-Jul-08, <draft-ietf-dnsext-rfc2672bis-dname-14.txt>
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.
"Measures for making DNS more resilient against forged answers", Bert Hubert,
Remco Mook, 17-Nov-08, <draft-ietf-dnsext-forgery-resilience-09.txt>
The current Internet climate poses serious threats to the Domain Name
System. In the interim period before the DNS protocol can be secured
more fully, measures can already be taken to harden the DNS to make
'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability
to discard bogus responses quickly, as this potentially saves large
amounts of computation.
By describing certain behaviour that has previously not been
standardised, this document sets out how to make the DNS more
resilient against accepting incorrect responses. This document
updates RFC 2181.
"Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis
Dupont, 19-Nov-08, <draft-ietf-dnsext-tsig-md5-deprecated-01.txt>
The main goal of this document is to deprecate the use of HMAC-MD5 as
an algorithm for the TSIG (secret key transaction authentication)
resource record in the DNS (domain name system).
Domain Name System Operations (dnsop)
-------------------------------------
"DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 14-Jul-08,
<draft-ietf-dnsop-respsize-11.txt>
With a mandated default minimum maximum UDP message size of 512
octets, the DNS protocol presents some special problems for zones
wishing to expose a moderate or high number of authority servers (NS
RRs). This document explains the operational issues caused by, or
related to this response size limit, and suggests ways to optimize
the use of this limited space. Guidance is offered to DNS server
implementors and to DNS zone operators.
"Locally-served DNS Zones", Mark Andrews, 10-Jul-08,
<draft-ietf-dnsop-default-local-zones-06.txt>
Experience has shown that there are a number of DNS zones all
iterative resolvers and recursive nameservers should, unless
configured otherwise, automatically serve. 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.
"Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson,
14-Jul-08, <draft-ietf-dnsop-resolver-priming-01.txt>
This document describes the initial queries a DNS resolver is
supposed to emit to initialize its cache with a current NS RRSet for
the root zone as well as the necessary address information.
"DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur
Gudmundsson, 14-Jul-08, <draft-ietf-dnsop-dnssec-trust-anchor-02.txt>
This document recommends a preferred format for specifying trust
anchors in DNSSEC validating security-aware resolvers and describes
how such a resolver should initialize trust anchors for use. This
document also describes different mechanisms for keeping trust
anchors up to date over time.
"Requirements for Management of Name Servers for the DNS", Wesley Hardaker,
3-Sep-08, <draft-ietf-dnsop-name-server-management-reqs-01.txt>
Management of name servers for the Domain Name Service (DNS) has
traditionally been done using vendor-specific monitoring,
configuration and control methods. Although some service monitoring
platforms can test the functionality of the DNS itself there is not a
interoperable way to manage (monitor, control and configure) the
internal aspects of a name server itself.
This document discusses the requirements of a management system for
DNS name servers. A management solution that is designed to manage
the DNS can use this document as a shopping list of needed features.
Data for Reachability of Inter/tra-NetworK SIP (drinks)
-------------------------------------------------------
"Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy,
Alan Duric, Edward Lewis, 7-Jul-08, <draft-ietf-drinks-cons-rqts-00.txt>
This document describes the type of data provisioned among Voice
Service Providers and underscores the need for clearly defined
structures and interfaces to facilitate this provisioning. This work
is in support of the service provider peering as defined by the
SPEERMINT WG.
Email Address Internationalization (eai)
----------------------------------------
"Downgrading mechanism for Email Address Internationalization", Kazunori
Fujiwara, Yoshiro Yoneya, 16-Sep-08, <draft-ietf-eai-downgrade-09.txt>
Traditional mail systems handle only ASCII characters in SMTP
envelope and mail header fields. The Email Address
Internationalization (UTF8SMTP) extension allows UTF-8 characters in
SMTP envelope and mail header fields. To avoid rejecting
internationalized Email messages when a server in the delivery path
does not support the UTF8SMTP extension, some sort of converting
mechanism is required. This document describes a downgrading
mechanism for Email Address Internationalization. Note that this is
a way to downgrade, not tunnel. There is no associated up-conversion
mechanism, although internationalized email clients might use
original internationalized addresses or other data when displaying or
replying to downgraded messages.
"IMAP Support for UTF-8", Pete Resnick, Chris Newman, 3-Nov-08,
<draft-ietf-eai-imap-utf8-04.txt>
This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support unencoded international
characters in user names, mail addresses and message headers. This
is an early draft and intended as a framework for discussion. Please
do not deploy implementations of this draft.
"Mailing Lists and Internationalized Email Addresses", Randall Gellens,
20-Nov-08, <draft-ietf-eai-mailinglist-04.txt>
This document describes considerations for mailing lists with the
introduction of internationalized email addresses.
This document makes some specific recommendations on how mailing
lists should act in various situations.
"POP3 Support for UTF-8", Chris Newman, Randall Gellens, 20-Nov-08,
<draft-ietf-eai-pop-05.txt>
This specification extends the Post Office Protocol version 3 (POP3)
to support un-encoded international characters in user names,
passwords, mail addresses, message headers, and protocol-level
textual error strings.
"Displaying Downgraded Messages for Email Address Internationalization",
Kazunori Fujiwara, 16-Oct-08, <draft-ietf-eai-downgraded-display-00.txt>
This document describes how to display downgraded messages which
originally contain internationalized E-mail addresses or
internationalized header fields.
Emergency Context Resolution with Internet Technologies (ecrit)
---------------------------------------------------------------
"Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne,
29-Sep-07, <draft-ietf-ecrit-mapping-arch-03.txt>
This document describes an architecture for a global, scalable,
resilient and administratively distributed system for mapping
geographic location information to URLs, using the Location-to-
Service (LoST) protocol. The architecture generalizes well-known
approaches found in hierarchical lookup systems such as DNS.
"Best Current Practice for Communications Services in support of Emergency
Calling", Brian Rosen, James Polk, 3-Nov-08,
<draft-ietf-ecrit-phonebcp-06.txt>
The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency
calls.
"Framework for Emergency Calling using Internet Multimedia", Brian Rosen,
Henning Schulzrinne, James Polk, Andrew Newton, 10-Jul-08,
<draft-ietf-ecrit-framework-06.txt>
The IETF has several efforts targeted at standardizing various
aspects of placing emergency calls. This document describes how all
of those component parts are used to support emergency calls from
citizens and visitors to authorities.
"Location Hiding: Problem Statement and Requirements", Henning Schulzrinne,
Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 12-Oct-08,
<draft-ietf-ecrit-location-hiding-req-01.txt>
The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points or VoIP service providers in order to
determine the correct dial string and information to route the call
to a Public Safety Answering Point (PSAP). For determining the PSAP
Uniform Resource Identifier (URI) the usage of the Location-to-
Service Translation (LoST) Protocol is envisioned.
This document explores the architectural impact for the IETF
emergency services architecture for situations where the Internet
Access Provider (IAP) and/or the Internet Service Provider (ISP) are
only willing to disclose limited or no location information.
This document provides a problem statement and lists requirements.
"Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin
Thomson, 12-Oct-08, <draft-ietf-ecrit-specifying-holes-01.txt>
This document describes how holes can be specified in geodetic
service boundaries. One means of implementing a search solution in a
service database, such as one might provide with a LoST server, is
described.
"Synchronizing Location-to-Service Translation (LoST) Servers", Henning
Schulzrinne, Hannes Tschofenig, 3-Nov-08, <draft-ietf-ecrit-lost-sync-01.txt>
The LoST (Location-to-Service Translation) protocol is used to map
locations to service URLs. This document defines a set of LoST
extensions that allow LoST servers to synchronize their lists of
mappings.
"IANA Registering a SIP Resource Priority Header Namespace for Local
Emergency Communications", James Polk, 27-Oct-08,
<draft-ietf-ecrit-local-emergency-rph-namespace-00.txt>
This document creates and IANA registers the new Session Initiation
Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
local emergency usage to a public safety answering point (PSAP),
between PSAPs, and between a PSAP and first responders and their
organizations.
EAP Method Update (emu)
-----------------------
"EAP Generalized Pre-Shared Key (EAP-GPSK) Method", Charles Clancy, Hannes
Tschofenig, 19-Nov-08, <draft-ietf-emu-eap-gpsk-17.txt>
This Internet Draft defines an Extensible Authentication Protocol
(EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This
method is a lightweight shared-key authentication protocol supporting
mutual authentication and key derivation.
"Requirements for an Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna,
Hao Zhou, Joseph Salowey, 31-Oct-08, <draft-ietf-emu-eaptunnel-req-01.txt>
This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and
the transport of additional data for other purposes.
Telephone Number Mapping (enum)
-------------------------------
"ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori
Fujiwara, 20-Nov-08, <draft-ietf-enum-experiences-11.txt>
This document captures experience in implementing systems based on
the ENUM protocol, and experience of ENUM data that have been created
by others. As such, it clarifies the ENUM and Dynamic Delegation
Discovery System standards. Its aim is to help others by reporting
what is "out there" and the potential pitfalls in interpreting the
set of documents that specify the protocol. It does not revise the
standards, but it is intended to provide technical input to future
revisions of those documents.
"IANA Registration for IAX Enumservice", Ed Guy, 17-Jun-08,
<draft-ietf-enum-iax-04.txt>
This document registers the IAX Enumservice using the URI scheme
'iax:' as per the IANA registration process defined in the ENUM
specification RFC3761.
"IANA Registration of Enumservices: Guide, Template and IANA Considerations",
Hoeneisen Bernie, Alexander Mayrhofer, Jason Livingood, 21-Nov-08,
<draft-ietf-enum-enumservices-guide-14.txt>
This document specifies a revision of the IANA Registration
Guidelines for Enumservices, describes corresponding registration
procedures, and provides a guideline for creating Enumservice
Specifications.
"A Telephone Number Mapping (ENUM) Service Registration for Internet
Calendaring Services", Rohan Mahy, 10-Mar-08,
<draft-ietf-enum-calendar-service-04.txt>
This document registers a Telephone Number Mapping (ENUM) service for
Internet Calendaring Services. Specifically, this document focuses
on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.
"The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application for Infrastructure ENUM", Jason Livingood,
3-Dec-07, <draft-ietf-enum-infrastructure-07.txt>
This document defines the use case for Infrastructure ENUM and
proposes its implementation as a parallel namespace to "e164.arpa" as
defined in RFC3761, as the long-term solution to the problem of
allowing carriers to provision DNS records for telephone numbers
independently of those provisioned by end users (number assignees).
"IANA Registration for an Enumservice Calling Name Delivery (CNAM)
Information and IANA Registration for URI type 'pstndata'", Richard Shockey,
29-Sep-08, <draft-ietf-enum-cnam-08.txt>
This document registers the Enumservice 'pstndata' and
subtype 'cnam' using the URI scheme 'pstndata:' as per the
IANA registration process defined in the ENUM specification,
RFC 3761 and registers a new URI type 'pstndata:'.
This data is used to facilitate the transfer of Calling Name
Delivery (CNAM) data for calls that originate on the Public
Switched Telephone Network (PSTN) that may be displayed on
VoIP or other Real-time Client User Agents (CUA). The
pstndata URI is created to facilitate this transfer, however
this URI may be used to transport other PSTN data in the
future.
"Combined User and Infrastructure ENUM in the e164.arpa tree", Michael
Haberler, Otmar Lendl, Richard Stastny, 22-Oct-07,
<draft-ietf-enum-combined-08.txt>
This memo defines an interim solution for Infrastructure ENUM to
allow a combined User and Infrastructure ENUM implementation in
e164.arpa as a national choice. This interim solution will be
deprecated after approval and implementation of the long-term
solution.
"ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06,
<draft-ietf-enum-edns0-00.txt>
Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this
document for DNS entities querying for or serving NAPTR records. In
general those entities will be supporting ENUM resolution. This
requirement is needed because DNS responses to ENUM-related queries
generally return large RRSets. Without EDNS0 support these lookups
would result in truncated responses and repeated queries over TCP
transport. That has a severe impact on DNS server load and on the
latency of those queries.
This document adds an operational requirement to use of the protocol
standardised in RFC 3761.
"The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori
Fujiwara, 31-Mar-08, <draft-ietf-enum-3761bis-03.txt>
This document discusses the use of the Domain Name System (DNS) for
the storage of E.164 numbers, and for resolving them into URIs that
can be used for (for example) telephony call setup. This document
also describes how the DNS can be used to identify the services
associated with an E.164 number. This document obsoletes RFC 3761.
"IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy,
Jim Reid, 29-Mar-08, <draft-ietf-enum-unused-04.txt>
This document registers the Enumservice "unused" using the URI scheme
"http:" as per the IANA registration process defined in the ENUM
specification, RFC 3761. This Enumservice may be used to indicate
that the E.164 number (or E.164 number range) tied to the domain in
which the enclosing NAPTR is published is not allocated or assigned
for communications service. When such an indication is provided, an
ENUM client can detect calls that will fail "early".
"IANA Registration for an Enumservice Trunkgroup", Richard Shockey, Tom
Creighton, 7-Jul-08, <draft-ietf-enum-trunkgroup-00.txt>
This document registers the Enumservice 'trunk' and subtypes 'sip'
and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA
registration process defined in the ENUM specification RFC 3761
[RFC7761].
RFC 4904 [RFC4904] defines a technique for the conveyance of carrying
trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's.
This Enumservice provides a mechanism for ENUM databases residing in
service provider networks a mechanism to query for that data.
FEC Framework (fecframe)
------------------------
"Forward Error Correction (FEC) Framework", Mark Watson, 24-Oct-08,
<draft-ietf-fecframe-framework-03.txt>
This document describes for a framework for using forward error
correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework
supports applying Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or
streaming, media. This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for
streaming media delivery or other packet flows. Content Delivery
Protocols defined using this framework can support any FEC Scheme
(and associated FEC codes) which is compliant with various
requirements defined in this document. Thus, Content Delivery
Protocols can be defined which are not specific to a particular FEC
Scheme and FEC Schemes can be defined which are not specific to a
particular Content Delivery Protocol.
"SDP Elements for FEC Framework", Ali Begen, 3-Nov-08,
<draft-ietf-fecframe-sdp-elements-02.txt>
This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s). This document also provides examples that
show the semantics for grouping multiple source and repair flows
together for the applications that simultaneously use multiple
instances of the FEC Framework.
"Methods to convey FEC Framework Configuration Information", Rajiv Asati,
3-Nov-08, <draft-ietf-fecframe-config-signaling-01.txt>
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).
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 27-Oct-08,
<draft-ietf-fecframe-interleaved-fec-scheme-01.txt>
This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity. The new payload format
defined in this document is used as a part of the DVB Application-
layer FEC Specification.
"DVB Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer,
29-Aug-08, <draft-ietf-fecframe-dvb-al-fec-00.txt>
This document describes the Application-layer Forward Error
Correction (FEC) protocol that was developed by the Digital Video
Broadcasting (DVB) consortium for the protection of media streams
over IP networks. The DVB AL-FEC protocol uses two layers for FEC
protection. The first (base) layer is based on the 1-D interleaved
parity code. The second (enhancement) layer is based on the Raptor
code. By offering a layered approach, the DVB AL-FEC offers a good
protection against both bursty and random packet losses at a cost of
decent complexity. The 1-D interleaved parity code and Raptor code
have already been specified in separate documents and the current
document normatively references these specifications.
"Raptor FEC Schemes for FECFRAME", Mark Watson, 24-Oct-08,
<draft-ietf-fecframe-raptor-00.txt>
This document describes Fully-Specified Forward Error Correction
(FEC) Schemes for the Raptor code and its application to reliable
delivery of media streams in the context of FEC Framework. The
Raptor code is a systematic code, where a number of repair symbols
are generated from a set of source symbols and sent in one or more
repair flows in addition to the source symbols that are sent to the
receiver(s) within a source flow. The Raptor code offers a close to
optimal protection against arbitrary packet losses at a low
computational complexity. Two FEC Schemes are defined, one for
protection of arbitrary packet flows and another for protection of a
single flow that already contains a sequence number. Repair data may
be sent over arbitrary datagram transport (e.g. UDP) or using RTP.
An RTP Payload Type is defined for this latter case.
"Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows
in FEC Framework", Ulas Kozat, Ali Begen, 26-Oct-08,
<draft-ietf-fecframe-pseudo-cdp-00.txt>
This document provides a pseudo Content Delivery Protocol (CDP) to
protect multiple source flows with one or more repair flows based on
the FEC Framework document and the Session Description Protocol (SDP)
elements defined for the framework. The purpose of the document is
not to provide a full-pledged protocol, but to show how the defined
framework and SDP elements can be combined together to design a CDP.
"RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", Ali
Begen, 27-Oct-08, <draft-ietf-fecframe-1d2d-parity-scheme-00.txt>
This document defines new RTP payload formats for the Forward Error
Correction (FEC) that is generated by the non-interleaved and
interleaved parity codes from a source media encapsulated in RTP.
These parity codes are systematic codes, where a number of repair
symbols are generated from a set of source symbols and sent in a
repair flow separate from the source flow that carries the source
symbols. The non-interleaved and interleaved parity codes offer a
good protection against random and bursty packet losses,
respectively, at a cost of decent complexity. The RTP payload
formats that are defined in this document address the scalability
issues experienced with the earlier specifications including RFC
2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due
to these changes, the new payload formats are not backward compatible
with the earlier specifications.
Forwarding and Control Element Separation (forces)
--------------------------------------------------
"ForCES Forwarding Element Model", Joel Halpern, Jamal Hadi Salim, 7-Oct-08,
<draft-ietf-forces-model-16.txt>
This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol [2]. The
model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so
that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES
requirements document, RFC3654 [6].
"ForCES Protocol Specification", Ligang Dong, Avri Doria, Ram Gopal, Robert
HAAS, Jamal Salim, Hormuzd Khosravi, Weiming Wang, 18-Nov-08,
<draft-ietf-forces-protocol-19.txt>
This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a
ForCES Network Element (ForCES NE). This specification is intended
to meet the ForCES protocol requirements defined in RFC3654. Besides
the ForCES protocol, this specification also defines the requirements
for the Transport Mapping Layer (TML).Authors
The participants in the ForCES Protocol Team, primary co-authors and
co-editors, of this protocol specification, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
University of Technology), Ram Gopal (Nokia), Robert Haas (IBM),
Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University). Special acknowledgement goes to
Joel Halpern who has done extensive editing in support of congruence
between the model and this protocol specification. Without his
participation and persistence, this specification might never have
been completed.
"ForCES MIB", Robert HAAS, 10-Sep-08, <draft-ietf-forces-mib-10.txt>
This memo defines a Management Information Base (MIB) module for use
with network management protocols in the Internet community. In
particular, it defines managed objects for the Forwarding and Control
Element Separation (ForCES) Network Element (NE).
"SCTP based TML (Transport Mapping Layer) for ForCES protocol", Jamal Hadi
Salim, Kentaro Ogawa, 14-Jul-08, <draft-ietf-forces-sctptml-01.txt>
This document defines the SCTP based TML (Transport Mapping Layer)
for the ForCES protocol. It explains the rationale for choosing the
SCTP (Stream Control Transmission Protocol) [RFC2960] and also
describes how this TML addresses all the requirements described in
[RFC3654] and the ForCES protocol [FE-PROTO] draft.
Geographic Location/Privacy (geopriv)
-------------------------------------
"Geolocation Policy: A Document Format for Expressing Privacy Preferences for
Location Information", Henning Schulzrinne, Hannes Tschofenig, John Morris,
Jorge Cuellar, James Polk, 26-Jun-08, <draft-ietf-geopriv-policy-17.txt>
This document defines an authorization policy language for
controlling access to location information. It extends the Common
Policy authorization framework to provide location-specific access
control. More specifically, this document defines condition elements
specific to location information in order to restrict access based on
the current location of the Target. Furthermore, it offers location-
specific transformation elements to reduce the granularity of the
returned location information.
"Carrying Location Objects in RADIUS and Diameter", Hannes Tschofenig, Farid
Adrangi, Mark Jones, Avi Lior, Bernard Aboba, 3-Nov-08,
<draft-ietf-geopriv-radius-lo-20.txt>
This document describes procedures for conveying access network
ownership and location information based on a civic and geospatial
location format in Remote Authentication Dial In User Service
(RADIUS) and Diameter.
The distribution of location information is a privacy sensitive task.
Dealing with mechanisms to preserve the user's privacy is important
and addressed in this document.
"GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations",
James Winterbottom, Martin Thomson, Hannes Tschofenig, 17-Sep-08,
<draft-ietf-geopriv-pdif-lo-profile-13.txt>
The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise
when information needs to be constrained in how it is represented.
In these circumstances the range of options that need to be
implemented are reduced. There is growing interest in being able to
use location information contained in a PIDF-LO for routing
applications. To allow successful interoperability between
applications, location information needs to be normative and more
tightly constrained than is currently specified in the RFC 4119
(PIDF-LO). This document makes recommendations on how to constrain,
represent and interpret locations in a PIDF-LO. It further
recommends a subset of GML that is mandatory to implement by
applications involved in location based routing.
"A Document Format for Filtering and Reporting Location Notications in the
Presence Information Document Format Location Object (PIDF-LO)", Rohan Mahy,
Brian Rosen, 3-Nov-08, <draft-ietf-geopriv-loc-filters-03.txt>
This document describes filters which limit asynchronous location
notifications to compelling events. The resulting location
information is conveyed in existing location formats wrapped in
GEOPRIV privacy extensions to the Presence Information Document
Format (PIDF-LO)
"GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements", Hannes Tschofenig, Henning Schulzrinne, 29-Jun-08,
<draft-ietf-geopriv-l7-lcp-ps-08.txt>
This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location
Information Server (LIS) that is located in the access network. The
obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as
input to the Location-to-Service Translation Protocol (LoST) or to
convey location within SIP to other entities.
"HTTP Enabled Location Delivery (HELD)", Mary Barnes, James Winterbottom,
Martin Thomson, Barbara Stark, 29-Oct-08,
<draft-ietf-geopriv-http-location-delivery-10.txt>
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
Security (HTTP/TLS) as transports for the protocol.
"Requirements for a Location-by-Reference Mechanism", Roger Marshall,
3-Nov-08, <draft-ietf-geopriv-lbyr-requirements-04.txt>
This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handle
location information within signaling and other Internet messaging.
"Discovering the Local Location Information Server (LIS)", Martin Thomson,
James Winterbottom, 30-Oct-08, <draft-ietf-geopriv-lis-discovery-04.txt>
A method is described for the discovery of a Location Information
Server. The method uses a Dynamic Host Configuration Protocol (DHCP)
option. DHCP options are defined for both IPv4 and IPv6 DHCP. A
URI-enabled NAPTR (U-NAPTR) method is described for use where the
DHCP option is unsuccessful. This document defines a U-NAPTR
Application Service for a LIS, with a specific Application Protocol
for the HTTP Enabled Location Delivery (HELD) protocol.
"Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform
Resource Identifier (URI)", James Polk, 3-Nov-08,
<draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt>
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the downloading of a Uniform Resource Identifier (URI)
pointing to the geolocation record of an endpoint. This URI, called
a Location-by-Reference (LbyR), points to a record on a location
server which tracks the geolocation of the endpoint. Once
downloaded by an endpoint, this LbyR can be forwarded to another
entity, to be dereferenced if this entity wants to learn the
geolocation of the sender endpoint.
"Implications of 'retransmission-allowed' for SIP Location Conveyance", Jon
Peterson, Ted Hardie, John Morris, 26-Oct-08,
<draft-ietf-geopriv-sip-lo-retransmission-01.txt>
This document explores an ambiguity in the interpretation of the
<retransmission-allowed> element of the Presence Information Data
Format for Location Objects (PIDF-LO) in cases where PIDF-LO is
conveyed by the Session Initiation Protocol (SIP). It provides
recommendations for how the SIP location conveyance mechanism should
adapt to these ambiguities.
Documents standardizing the SIP location conveyance mechanisms will
be standards-track documents processed according to the usual SIP
process. This document is intended primarily to provide the SIP
working group with a statement of the consensus of the GEOPRIV
working group on this topic. It secondarily provides tutorial
information on the problem space for the general reader.
"Considerations for Civic Addresses in PIDF-LO", Karl Wolf, Alexander
Mayrhofer, 27-Oct-08,
<draft-ietf-geopriv-civic-address-recommendations-00.txt>
This document provides a guideline for creating civic address
consideration documents for individual countries, as required by RFC
4776. Since civic addresses may have a different format in
individual countries, such address considerations are necessary in
order to map the civic address fields to the PIDF Location Object
(PIDF-LO) elements.
Global Routing Operations (grow)
--------------------------------
"MRT routing information export format", Larry Blunk, Manish Karir, Craig
Labovitz, 14-Jul-08, <draft-ietf-grow-mrt-08.txt>
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.
"BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart,
19-Nov-08, <draft-ietf-grow-bmp-00.txt>
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.
Host Identity Protocol (hip)
----------------------------
"Basic HIP Extensions for Traversal of Network Address Translators", Miika
Komu, Tom Henderson, Philip Matthews, Hannes Tschofenig, Ari Keraenen,
31-Oct-08, <draft-ietf-hip-nat-traversal-05.txt>
This document specifies extensions to the Host Identity Protocol
(HIP) to facilitate Network Address Translator (NAT) traversal. The
extensions are based on the use of the Interactive Connectivity
Establishment (ICE) methodology to discover a working path between
two end-hosts, and on standard techniques for encapsulating
Encapsulating Security Payload (ESP) packets within the User Datagram
Protocol (UDP). This document also defines elements of procedure for
NAT traversal, including the optional use of a HIP relay server.
With these extensions HIP is able to work in environments that have
NATs and provides a generic NAT traversal solution to higher-layer
networking applications.
"Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika
Komu, Tom Henderson, 14-Jul-08, <draft-ietf-hip-native-api-05.txt>
This document defines extensions to the current sockets API for 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 document are experimental and
provide basic tools for futher experimentation with policies.
"HIP Certificates", Tobias Heer, Samu Varjonen, 21-Oct-08,
<draft-ietf-hip-cert-00.txt>
This document specifies a certificate parameter called CERT for the
Host Identity Protocol (HIP). The CERT parameter is a container for
Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates.
It is used for carrying these certificates in HIP control messages.
Additionally, this document specifies the representations of Host
Identity Tags in SPKI and X.509.v3 certificates.
"HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
Environment", Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, Alan
Johnston, 27-Oct-08, <draft-ietf-hip-bone-00.txt>
This document specifies a framework to build HIP (Host Identity
Protocol)-based overlay networks. This framework uses HIP to perform
connection management. Other functions, such as data storage and
retrieval or overlay maintenance, are implemented using protocols
other than HIP. These protocols are loosely referred to as peer
protocols.
Handover Keying (hokey)
-----------------------
"Derivation, delivery and management of EAP based keys for handover and
re-authentication", Yoshihiro Ohba, 19-Oct-08,
<draft-ietf-hokey-key-mgm-04.txt>
This document describes a mechanism for delivering a usage-specific
root key (USRK), a domain-specific root key (DSRK) and a usage-
specific domain-specific root key (USDSRK) using RADIUS. The root
keys are derived as part of an Extended Master Session Key (EMSK)
hierarchy in Extensible Authentication Protocol (EAP), and delivered
from a server to an intended third-party key holder. The mechanism
supports different scenarios for key delivery, depending on the type
of keys being delivered. The mechanism description includes the
definition for a key distribution exchange (KDE) protocol.
"EAP Pre-authentication Problem Statement", Yoshihiro Ohba, 9-Sep-08,
<draft-ietf-hokey-preauth-ps-04.txt>
EAP (Extensible Authentication Protocol) pre-authentication is
defined as the use of EAP to pre-establish EAP keying material on a
target authenticator prior to arrival of the peer at the access
network managed by that authenticator. This draft discusses EAP pre-
authentication problems in detail.
Hypertext Transfer Protocol Bis (httpbis)
-----------------------------------------
"HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim
Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim
Berners-Lee, Julian Reschke, 17-Nov-08,
<draft-ietf-httpbis-p1-messaging-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the
"http" and "https" Uniform Resource Identifier (URI) schemes, defines
the generic message syntax and parsing requirements for HTTP message
frames, and describes general security concerns for implementations.
"HTTP/1.1, part 2: Message Semantics", Roy Fielding, Jim Gettys, Jeffrey
Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian
Reschke, 17-Nov-08, <draft-ietf-httpbis-p2-semantics-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header
fields.
"HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding,
Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim
Berners-Lee, Julian Reschke, 17-Nov-08,
<draft-ietf-httpbis-p3-payload-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 3 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
HTTP message content, metadata, and content negotiation.
"HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Jim Gettys, Jeffrey
Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian
Reschke, 17-Nov-08, <draft-ietf-httpbis-p4-conditional-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 4 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
request header fields for indicating conditional requests and the
rules for constructing responses to those requests.
"HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Jim
Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim
Berners-Lee, Julian Reschke, 17-Nov-08, <draft-ietf-httpbis-p5-range-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 5 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
range-specific requests and the rules for constructing and combining
responses to those requests.
"HTTP/1.1, part 6: Caching", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik
Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke,
17-Nov-08, <draft-ietf-httpbis-p6-cache-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 6 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines
requirements on HTTP caches and the associated header fields that
control cache behavior or indicate cacheable response messages.
"HTTP/1.1, part 7: Authentication", Roy Fielding, Jim Gettys, Jeffrey Mogul,
Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke,
17-Nov-08, <draft-ietf-httpbis-p7-auth-05.txt>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 7 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines
HTTP Authentication.
"Security Requirements for HTTP", Paul Hoffman, Alexey Melnikov, 13-Jul-08,
<draft-ietf-httpbis-security-properties-02.txt>
Recent IESG practice dictates that IETF protocols must specify
mandatory-to-implement security mechanisms, so that all conformant
implementations share a common baseline. This document examines all
widely deployed HTTP security technologies, and analyzes the trade-
offs of each.
"Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian
Reschke, 29-Aug-08, <draft-ietf-httpbis-method-registrations-00.txt>
This document registers those Hypertext Transfer ProtocolHypertext
Transfer Protocol (HTTP) methods which have been defined in
standards-track RFCs before the IANA HTTP Method Registry was
established.
Internet Architecture Board (iab)
---------------------------------
"Defining the Role and Function of IETF Protocol Parameter Registry
Operators", Geoff Huston, 22-Oct-08, <draft-iab-iana-04.txt>
Many IETF protocols make use of commonly defined values that are
passed within protocol objects. To ensure consistent interpretation
of these values between independent implementations, there is a need
to ensure that the values and associated semantic intent are uniquely
defined. The IETF uses registry functions to record assigned
protocol parameter values and their associated semantic intent. For
each IETF protocol parameter it is current practice for the IETF to
delegate the role of protocol parameter registry operator to a
nominated entity. This document provides a description of and the
requirements for these delegated functions.
"Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter
Koch, 11-Aug-08, <draft-iab-dns-choices-07.txt>
This note discusses how to extend the DNS with new data for a new
application. DNS extension discussions too often focus on reuse of
the TXT Resource Record Type. This document lists different
mechanisms to extend the DNS, and concludes that the use of a new DNS
Resource Record Type is the best solution.
Internationalized Domain Names in Applications (Revised) (idnabis)
------------------------------------------------------------------
"The Unicode code points and IDNA", Patrik Faltstrom, 19-Nov-08,
<draft-ietf-idnabis-tables-04.txt>
This document specifies rules for deciding whether a code point,
considered in isolation, is a candidate for inclusion in an
Internationalized Domain Name.
It is part of the specification of IDNA2008.
"Internationalized Domain Names for Applications (IDNA): Background,
Explanation, and Rationale", John Klensin, 3-Nov-08,
<draft-ietf-idnabis-rationale-04.txt>
Several years have passed since the original protocol for
Internationalized Domain Names (IDNs) was completed and deployed.
During that time, a number of issues have arisen, including the need
to update the system to deal with newer versions of Unicode. Some of
these issues require tuning of the existing protocols and the tables
on which they depend. This document provides an overview of a
revised system and provides explanatory material for its components.
"Internationalized Domain Names in Applications (IDNA): Protocol", John
Klensin, 2-Nov-08, <draft-ietf-idnabis-protocol-06.txt>
This document supplies the protocol definition for a revised and
updated specification for internationalized domain names (IDNs). The
rationale for these changes, the relationship to the older
specification, and important terminology are provided in other
documents. This document specifies the protocol mechanism, called
Internationalizing Domain Names in Applications (IDNA), for
registering and looking up IDNs in a way that does not require
changes to the DNS itself. IDNA is only meant for processing domain
names, not free text.
"An updated IDNA criterion for right-to-left scripts", Harald Alvestrand,
Cary Karp, 30-Jul-08, <draft-ietf-idnabis-bidi-02.txt>
The use of right-to-left scripts in internationalized domain names
has presented several challenges. This memo discusses some problems
with these scripts, and some shortcomings in the 2003 IDNA BIDI
criterion. Based on this discussion, it proposes a new BIDI
criterion for IDNA labels.
"Internationalized Domain Names for Applications (IDNA): Definitions and
Document Framework", John Klensin, 18-Nov-08,
<draft-ietf-idnabis-defs-02.txt>
This document is one of a collection that, together, describe the
protocol and usage context for a revision of Internationalized Domain
Names for Applications (IDNA), superseding the earlier version. It
describes the document collection and provides definitions and other
material that are common to the set.
Inter-Domain Routing (idr)
--------------------------
"Definitions of Managed Objects for the Fourth Version of Border Gateway
Protocol (BGP-4), Second Version", Jeffrey Haas, 2-Nov-08,
<draft-ietf-idr-bgp4-mibv2-08.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing the Border Gateway Protocol, Version 4.
"Dissemination of flow specification rules", Pedro Roque Marques, Nischal
Sheth, Robert Raszuk, Barry Greene, Danny McPherson, 20-Nov-08,
<draft-ietf-idr-flow-spec-03.txt>
This document defines a new BGP NLRI encoding format that can be used
to distribute traffic flow specifications. This allows the routing
system to propagate information regarding more-specific components of
the traffic aggregate defined by an IP destination prefix.
Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic
filtering, such as what is required in order to mitigate
(distributed) denial of service attacks. And a second application to
traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the Border Gateway Protocol (BGP),
thereby reusing protocol algorithms, operational experience and
administrative processes such as inter-provider peering agreements.
"Capabilities Advertisement with BGP-4", John Scudder, Ravi Chandra,
18-Nov-08, <draft-ietf-idr-rfc3392bis-01.txt>
This document defines an Optional Parameter, called Capabilities,
that is expected to facilitate the introduction of new capabilities
in the Border Gateway Protocol (BGP) by providing graceful capability
advertisement without requiring that BGP peering be terminated. This
document obsoletes RFC 3392.
"Textual Representation of AS Numbers", Geoff Huston, George Michaelson,
22-Sep-08, <draft-ietf-idr-as-representation-01.txt>
A textual representation for Autonomous System (AS) numbers is
defined as the decimal value of the AS Number. This textual
representation is to be used by all documents, systems and user
interfaces referring to AS numbers.
"AS Number Reservation for Documentation Use", Geoff Huston, 3-Oct-08,
<draft-ietf-idr-as-documentation-reservation-00.txt>
To reduce the likelihood of conflict and confusion when relating
documented examples to deployed systems, two blocks of Autonomous
System numbers (ASNs) are reserved for use in examples in RFCs,
books, documentation, and the like. This document describes the
reservation of two blocks of ASNs as reserved numbers for use in
documentation.
IP over Cable Data Network (ipcdn)
----------------------------------
"Management Event Management Information Base (MIB) for PacketCable- and
IPCablecom-Compliant Devices", Sumanth Channabasappa, Intellectual Property,
17-Aug-08, <draft-ietf-ipcdn-pktc-eventmess-14.txt>
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 events that
can be generated by PacketCable- and IPCablecom-compliant Multimedia
Terminal Adapter devices.
De Ketelaere/Nechamkin/Channabasappa Expires - February 2009 [page 1]
PacketCable/IPCablecom Event management MTA MIB
August 2008
IP over DVB (ipdvb)
-------------------
"Security requirements for the Unidirectional Lightweight Encapsulation (ULE)
protocol", Prashant Pillai, Michael Noisternig, 23-Aug-08,
<draft-ietf-ipdvb-sec-req-09.txt>
The MPEG-2 standard defined by ISO 13818-1 supports a range of
transmission methods for a range of services. This document
provides a threat analysis and derives the security requirements
when using the Transport Stream, TS, to support an Internet
network-layer using Unidirectional Lightweight Encapsulation
(ULE) defined in RFC4326. The document also provides the
motivation for link-layer security for a ULE Stream. A ULE Stream
may be used to send IPv4 packets, IPv6 packets, and other
Protocol Data Units (PDUs) to an arbitrarily large number of
Receivers supporting unicast and/or multicast transmission.
The analysis also describes applicability to the Generic Stream
Encapsulation (GSE) defined by the Digital Video Broadcasting
(DVB) Project.
IP Flow Information Export (ipfix)
----------------------------------
"Architecture for IP Flow Information Export", Ganesh Sadasivan, 10-Sep-06,
<draft-ietf-ipfix-architecture-12.txt>
This memo defines the IP Flow Information eXport (IPFIX) architecture
for the selective monitoring of IP flows, and for the export of
measured IP flow information from an IPFIX device to a collector.
"IPFIX Applicability", Tanja Zseby, 3-Jul-07, <draft-ietf-ipfix-as-12.txt>
In this document we describe the applicability of the IP Flow
Information Export (IPFIX) protocol for a variety of
applications. We show how applications can use IPFIX, describe
the relevant information elements (IEs) for those applications
and present opportunities and limitations of the protocol. We
furthermore describe relations of the IPFIX framework to other
architectures and frameworks.
"Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet
Sampling (PSAMP) Reports", Elisa Boschi, 21-May-07,
<draft-ietf-ipfix-reducing-redundancy-04.txt>
This document describes a bandwidth saving method for exporting flow
or packet information using the IP Flow Information Export (IPFIX)
protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX,
these considerations are valid for PSAMP exports as well.
This method works by separating information common to several flow
records from information specific to an individual flow record.
Common flow information is exported only once in a data record
defined by an option template, while the rest of the specific flow
information is associated with the common information via a unique
identifier.
"Guidelines for IP Flow Information eXport (IPFIX) Testing", Carsten Schmoll,
Paul Aitken, Benoit Claise, 16-Apr-08, <draft-ietf-ipfix-testing-05.txt>
This document presents a list of tests for implementers of IP Flow
Information Export (IPFIX) compliant Exporting Processes and
Collecting Processes. This document specifies guidelines for a
series of tests that can be run on the IPFIX Exporting Process and
Collecting Process in order to probe the conformity and robustness of
the IPFIX protocol implementations. These tests cover all important
functions, in order to gain a level of confidence in the IPFIX
implementation. Therefore they allow the implementer to perform
interoperability or plug tests with other IPFIX Exporting Processes
and Collecting Processes.
"Definitions of Managed Objects for IP Flow Information Export", Thomas
Dietz, Atsushi Kobayashi, Benoit Claise, 3-Nov-08,
<draft-ietf-ipfix-mib-05.txt>
This document defines managed objects for IP Flow Information Export
(IPFIX). These objects provide information for monitoring IPFIX
Exporters and IPFIX Collectors including the basic configuration
information.
"Specification of the IPFIX File Format", Brian Trammell, Elisa Boschi, Lutz
Mark, Tanja Zseby, Arno Wagner, 24-Oct-08, <draft-ietf-ipfix-file-03.txt>
This document describes a file format for the storage of flow data
based upon the IPFIX Protocol. It proposes a set of requirements for
flat-file, binary flow data file formats, then specifies the IPFIX
File format to meet these requirements based upon IPFIX Messages.
This IPFIX File format is designed to facilitate interoperability and
reusability among a wide variety of flow storage, processing, and
analysis tools.
"Exporting Type Information for IPFIX Information Elements", Elisa Boschi,
Brian Trammell, Lutz Mark, Tanja Zseby, 14-Jul-08,
<draft-ietf-ipfix-exporting-type-02.txt>
This document describes an extension to IPFIX to allow the encoding
of IPFIX Information Model properties within an IPFIX Message stream.
This enables the export of extended type information for enterprise-
specific Information Elements, facilitating interoperability and
reusability among a wide variety of applications and tools.
"IPFIX Mediation: Problem Statement", Atsushi Kobayashi, Haruhiko Nishida,
Christoph Sommer, Falko Dressler, Emile Stephan, Benoit Claise, 26-Sep-08,
<draft-ietf-ipfix-mediators-problem-statement-01.txt>
Flow-based measurement is currently a popular method for various
network monitoring usages. The sharing of flow-based information
among orthogonal monitoring applications raises open issues in terms
of scalability, reliability and flexibility that IPFIX Mediation may
help resolve. IPFIX Mediation reroutes, replicates, filters,
aggregates, correlates or modifies Flow Records or Packet Reports, or
changes a transport protocol. This document describes the
applicability of IPFIX Mediation and the problems that IPFIX
Mediation might encounter.
"IPFIX Mediation: Framework", Atsushi Kobayashi, Haruhiko Nishida, Benoit
Claise, 3-Nov-08, <draft-ietf-ipfix-mediators-framework-01.txt>
This document describes a framework for an IPFIX Mediation. This
framework details an IPFIX Mediation reference model and the
components of the IPFIX Mediation device (IPFIX Mediator).
"IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson,
Gerhard Muenz, 3-Nov-08, <draft-ietf-ipfix-export-per-sctp-stream-01.txt>
This document specifies an improvement to the PR-SCTP
export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to
calculate Data Record losses for PR-SCTP, immediate export of
Template Withdrawal Messages, immediate reuse of Template IDs
within an SCTP stream, and reduced demands on the Collecting
Process.
"Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise,
3-Nov-08, <draft-ietf-ipfix-configuration-model-01.txt>
This document specifies a data model for the configuration of caches,
selection processes, exporting processes, and collecting processes of
IPFIX and PSAMP compliant monitoring devices. The configuration data
model is encoded in Extensible Markup Language (XML). The structure
of the data model is specified in a YANG module to ensure
compatibility with the NETCONF protocol. A YANG-to-XSD converter is
available which allows generating an XML Schema Definition (XSD) of
the data model.
IP Performance Metrics (ippm)
-----------------------------
"IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, Lei
Liang, Al Morton, 15-Oct-08, <draft-ietf-ippm-multimetrics-09.txt>
The IETF has standardized IP Performance Metrics (IPPM) for measuring
end-to-end performance between two points. This memo defines two new
categories of metrics that extend the coverage to multiple
measurement points. It defines spatial metrics for measuring the
performance of segments of a source to destination path, and metrics
for measuring the performance between a source and many destinations
in multiparty communications (e.g., a multicast tree).
"Spatial Composition of Metrics", Al Morton, Emile Stephan, 13-Jul-08,
<draft-ietf-ippm-spatial-composition-07.txt>
This memo utilizes IPPM metrics that are applicable to both complete
paths and sub-paths, and defines relationships to compose a complete
path metric from the sub-path metrics with some accuracy w.r.t. the
actual metrics. This is called Spatial Composition in RFC 2330. The
memo refers to the Framework for Metric Composition, and provides
background and motivation for combining metrics to derive others.
The descriptions of several composed metrics and statistics follow.
"Framework for Metric Composition", Al Morton, 29-Oct-08,
<draft-ietf-ippm-framework-compagg-07.txt>
This memo describes a detailed framework for composing and
aggregating metrics (both in time and in space) originally defined by
the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF.
This new framework memo describes the generic composition and
aggregation mechanisms. The memo provides a basis for additional
documents that implement the framework to define detailed
compositions and aggregations of metrics which are useful in
practice.
"Reporting IP Performance Metrics to Users", Stanislav Shalunov, Martin
Swany, 14-Jul-08, <draft-ietf-ippm-reporting-02.txt>
The aim of this document is to define a small set of metrics that are
robust, easy to understand, orthogonal, relevant, and easy to
compute. The IPPM WG has defined a large number of richly
parameterized metrics because network measurement has many purposes.
Often, the ultimate purpose is to report a concise set of metrics
describing a network's state to an end user. It is for this purpose
that the present set of metrics is defined.
"Information Model and XML Data Model for Traceroute Measurements", Saverio
Niccolini, Sandra Tartarelli, Juergen Quittek, Thomas Dietz, Martin Swany,
23-Oct-08, <draft-ietf-ippm-storetraceroutes-12.txt>
This document describes a standard way to store the configuration and
the results of traceroute measurements. This document first of all
describes the terminology used in this document and the traceroute
tool itself; afterwards, the common information model is defined
dividing the information elements in two semantically separated
groups (configuration elements and results elements). Moreover an
additional element is defined to relate configuration elements and
results elements by means of a common unique identifier. On the
basis of the information model a data model based on XML is defined
to store the results of traceroute measurements.
"A One-Way Packet Duplication Metric", Henk Uijterwaal, 7-Oct-08,
<draft-ietf-ippm-duplicate-05.txt>
When a packet is sent from one host to the other, one normally
expects that exactly one copy of the packet that was sent arrives at
the destination. It is, however, possible that a packet is either
lost or that multiple copies arrive.
In earlier work a metric for packet loss has been defined. This
metric quantifies the case where a packet that is sent, does not
arrive at its destination within a reasonable time. In this memo, a
metric for another case is defined: a packet is sent, but multiple
copies arrive. The document also discusses streams and methods to
summarize the results of streams.
"Packet Delay Variation Applicability Statement", Al Morton, Benoit Claise,
13-Jul-08, <draft-ietf-ippm-delay-var-as-01.txt>
Packet delay variation metrics appear in many different standards
documents. The metric definition in RFC 3393 has considerable
flexibility, and it allows multiple formulations of delay variation
through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas,
it can make comparisons of independent implementations more
difficult. Two different formulations of delay variation have come
into wide use in the context of active measurements. This memo
examines a range of circumstances for active measurements of delay
variation and their uses, and recommends which of the two forms is
best matched to particular conditions and tasks.
"More Features for TWAMP", Al Morton, Kaynam Hedayat, 20-Oct-08,
<draft-ietf-ippm-more-twamp-00.txt>
The IETF has completed its work on TWAMP - the Two-Way Active
Measurement Protocol. This memo describes a simple extension to
TWAMP, the option to use different security modes in the TWAMP-
Control and TWAMP-Test protocols.
"TWAMP Reflect Octets Feature", Al Morton, Len Ciavattone, 26-Oct-08,
<draft-ietf-ippm-twamp-reflect-octets-00.txt>
The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes a new
feature for TWAMP: an optional capability where the responder host
returns some of the command octets or padding octets to the
controller, and/or ensures that the same test packet sizes are used
in both directions.
"Individual Session Control Feature for TWAMP", Al Morton, Murtaza Chiba,
27-Oct-08, <draft-ietf-ippm-twamp-session-cntrl-00.txt>
The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes a new
feature for TWAMP, that gives the controlling host the ability to
start and stop one or more individual test sessions using their
Session Identifiers. The base capability of the TWAMP protocol
requires all test sessions previously requested and accepted to start
and stop at the same time.
IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------
"Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Yoav
Nir, Pasi Eronen, 30-Oct-08, <draft-ietf-ipsecme-ikev2bis-01.txt>
This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations
(SAs). It replaces and updates RFC 4306, and includes all of the
clarifications from RFC 4718.
"Re-direct Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, 3-Nov-08,
<draft-ietf-ipsecme-ikev2-redirect-01.txt>
IKEv2 is a popular protocol for setting up VPN tunnels from a remote
location to a gateway so that the VPN client can access services in
the network behind the gateway. Currently there is no standard
mechanism specified that allows an overloaded VPN gateway to re-
direct the VPN client to attach to another gateway. This document
proposes a re-direct mechanism for IKEv2. The proposed mechanism can
also be used for Mobile IPv6 to enable the home agent to re-direct
the mobile node to another home agent.
"Wrapped ESP for Traffic Visibility", Ken Grewal, Gabriel Montenegro,
22-Oct-08, <draft-ietf-ipsecme-traffic-visibility-00.txt>
This document describes an ESP encapsulation for IPsec, allowing
intermediate devices to ascertain if ESP-NULL is being employed
and hence inspect the IPsec packets for network monitoring and
access control functions. Currently in the IPsec standard,
there is no way to differentiate between ESP encryption and ESP
NULL encryption by simply examining a packet.
"IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath
Dondeti, Vidya Narayanan, 17-Nov-08,
<draft-ietf-ipsecme-ikev2-resumption-00.txt>
The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips
and consequently latency.
To re-establish security associations (SA) upon a failure recovery
condition is time consuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.
The proposed approach uses a IKEv2 state (or a reference into a state
store). to store state information that is later made available to
the IKEv2 responder for re-authentication. Restoring state
information by utilizing a ticket is one possible way. This document
does not specify the format of the ticket but recommendations are
provided.
"IPv6 Configuration in IKEv2", Pasi Eronen, Julien Laganier, Cheryl Madson,
18-Nov-08, <draft-ietf-ipsecme-ikev2-ipv6-config-00.txt>
When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. This document describes the
limitations of current IKEv2 configuration payloads for IPv6, and
explores possible solutions that would allow IKEv2 to set up full-
featured virtual IPv6 interfaces.
IP Security Policy (ipsp)
-------------------------
"IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 10-Nov-06,
<draft-ietf-ipsp-ipsecaction-mib-02.txt>
This document defines an SMIv2 Management Information Base (MIB)
module for configuring IPsec actions for the security policy database
(SPD) of a device that uses the IPsec Security Policy Database
Configuration MIB for configuring the IPSec protocol actions on that
device. The IPsec Action MIB integrates directly with the IPsec
Security Policy Database Configuration MIB and it is meant to work
within the framework of an action referenced by that MIB.
"IPsec Security Policy IKE Action MIB", Wesley Hardaker, 10-Nov-06,
<draft-ietf-ipsp-ikeaction-mib-02.txt>
This document defines a SMIv2 Management Information Base (MIB)
module for configuring Internet Key Exchange (IKE) actions for the
security policy database (SPD) of a device that uses the IPsec
Security Policy Database Configuration MIB for configuring the IKE
protocol actions on that device. The IPsec IKE Action MIB integrates
directly with the IPsec Security Policy Database Configuration MIB
and it is meant to work within the framework of an action referenced
by that MIB.
IS-IS for IP Internets (isis)
-----------------------------
"IPv6 Traffic Engineering in IS-IS", Jon Harrison, 26-Jun-08,
<draft-ietf-isis-ipv6-te-05.txt>
This document specifies a method for exchanging IPv6 Traffic
Engineering information using the IS-IS routing protocol. The
described method uses three new TLVs, together with two new sub-TLVs
of the Extended IS Reachability TLV. The information distributed
allows a CSPF algorithm to calculate traffic engineered routes using
IPv6 addresses.
"Simplified Extension of LSP Space for IS-IS", Les Ginsberg, Stefano Previdi,
Mike Shand, Danny McPherson, 18-Nov-08, <draft-ietf-isis-wg-extlsp-04.txt>
This draft describes a simplified method for extending the LSP space
beyond the 256 Link State PDU (LSP) limit defined in [IS-IS]. This
method is intended as a preferred replacement for the method defined
in [RFC 3786].
"IS-IS Generic Cryptographic Authentication", Manav Bhatia, 18-Nov-08,
<draft-ietf-isis-hmac-sha-07.txt>
This document proposes an extension to Intermediate System to
Intermediate System (IS-IS) to allow the use of any cryptographic
authentication algorithm in addition to the already documented
authentication schemes, described in the base specification and RFC
5304. IS-IS is specified in International Standards Organization
(ISO) 10589, with extensions to support Internet Protocol version 4
(IPv4) described in RFC 1195.
Although this document has been written specifically for using the
Hashed Message Authentication Code (HMAC) construct along with the
Secure Hash Algorithm (SHA) family of cryptographic hash functions,
the method described in this document is generic and can be used to
extend IS-IS to support any cryptographic hash function in the
future.
"Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi,
Mike Shand, 20-Jun-08, <draft-ietf-isis-genapp-01.txt>
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.
"IS-IS Multi-Instance", Stefano Previdi, Les Ginsberg, Mike Shand, David
Ward, Abhay Roy, 29-Oct-08, <draft-ietf-isis-mi-01.txt>
This draft describes a mechanism that allows a single router to share
one or more links among multiple IS-IS routing protocol instances.
Multiple instances allow the isolation of resources associated with
each instance. Routers will form instance specific adjacencies,
exchange instance specific routing updates and compute paths
utilizing instance specific LSDB information. Each PDU will contain
a new TLV identifying the instance to which the PDU belongs. This
allows a network operator to deploy multiple IS-IS instances in
parallel, using the same set of links when required and still have
the capability of computing instance specific paths. This draft does
not address the forwarding paradigm that needs to be used in order to
ensure data PDUs are forwarded according to the paths computed by a
specific instance.
Integrated Security Model for SNMP (isms)
-----------------------------------------
"Secure Shell Transport Model for SNMP", David Harrington, Joseph Salowey,
Wesley Hardaker, 3-Nov-08, <draft-ietf-isms-secshell-13.txt>
This memo describes a Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol (SSH).
This memo also 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 monitoring and
managing the Secure Shell Transport Model for SNMP.
"Transport Subsystem for the Simple Network Management Protocol (SNMP)",
David Harrington, Juergen Schoenwaelder, 31-Oct-08,
<draft-ietf-isms-tmsm-15.txt>
This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work
is being done to expand the transports to include secure transports
such as SSH and TLS, using a subsystem will enable consistent design
and modularity of such Transport Models. This document identifies
and describes some key aspects that need to be considered for any
Transport Model for SNMP.
"Transport Security Model for SNMP", David Harrington, Wesley Hardaker,
31-Oct-08, <draft-ietf-isms-transport-security-model-10.txt>
This memo describes a Transport Security Model for the Simple Network
Management Protocol.
This memo also defines a portion of the Management Information Base
(MIB) for monitoring and managing the Transport Security Model for
SNMP.
"Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network
Management Protocol (SNMP) Transport Models", Kaushik Narayan, David Nelson,
12-Oct-08, <draft-ietf-isms-radius-usage-04.txt>
This memo describes the use of a Remote Authentication Dial-In User
Service (RADIUS) authentication and authorization service by Simple
Network Management Protocol (SNMP) secure Transport Models to
authenticate users and authorize creation of secure transport
sessions. While the recommendations of this memo are generally
applicable to a broad class of SNMP Transport Models, the examples
focus on the Secure Shell Transport Model.
Provisioning of Symmetric Keys (keyprov)
----------------------------------------
"Dynamic Symmetric Key Provisioning Protocol (DSKPP)", Andrea Doherty,
Mingliang Pei, Salah Machani, Magnus Nystrom, 3-Nov-08,
<draft-ietf-keyprov-dskpp-06.txt>
DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible
cryptographic modules. The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure.
Two variations of the protocol support multiple usage scenarios.
With the four-pass variant, keys are mutually generated by the
provisioning server and cryptographic module; provisioned keys are
not transferred over-the-wire or over-the-air. The two-pass variant
enables secure and efficient download and installation of pre-
generated symmetric keys to a cryptographic module.
This document builds on information contained in [RFC4758], adding
specific enhancements in response to implementation experience and
liaison requests.
"Portable Symmetric Key Container", Mingliang Pei, Salah Machani, Philip
Hoyer, 3-Nov-08, <draft-ietf-keyprov-portable-symmetric-key-container-06.txt>
This document specifies a symmetric key format for transport and
provisioning of symmetric keys (for example One Time Password (OTP)
shared secrets or symmetric cryptographic keys) to different types of
crypto modules such as a strong authentication device. The standard
key transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.
This work is based on earlier work by the members of OATH (Initiative
for Open AuTHentication) to specify a format that can be freely
distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations.
"Symmetric Key Package Content Type", Sean Turner, Russ Housley, 14-Jul-08,
<draft-ietf-keyprov-symmetrickeyformat-03.txt>
This document defines the symmetric key format content type. It is
transport independent. The Cryptographic Message Syntax can be used
to digitally sign, digest, authenticate, or encrypt this content
type.
Kitten (GSS-API Next Generation) (kitten)
-----------------------------------------
"Generic Security Service API Version 2 : Java Bindings Update", Mayan
Upadhyay, Seema Malkani, 8-Jul-08, <draft-ietf-kitten-rfc2853bis-04.txt>
The Generic Security Services Application Program Interface (GSS-API)
offers application programmers uniform access to security services
atop a variety of underlying cryptographic mechanisms. This document
updates the Java bindings for the GSS-API that are specified in
"Generic Security Service API version 2 : Java Bindings" (RFC2853).
This document obsoletes RFC 2853 by making specific and incremental
clarifications and corrections to it in response to identification of
transcription errors and implementation experience.
The GSS-API is described at a language independent conceptual level
in "Generic Security Service Application Program Interface Version 2,
Update 1" (RFC2743). The GSS-API allows a caller application to
authenticate a principal identity, to delegate rights to a peer, and
to apply security services such as confidentiality and integrity on a
per-message basis. Examples of security mechanisms defined for GSS-
API are "The Simple Public-Key GSS-API Mechanism" (RFC2025) and "The
Kerberos Version 5 GSS-API Mechanism (RFC4121).
"Clarifications and Extensions to the GSS-API for the Use of Channel
Bindings", Nicolas Williams, 23-Sep-08,
<draft-ietf-kitten-gssapi-channel-bindings-05.txt>
This document clarifies and generalizes the Generic Security Services
Application Programming Interface (GSS-API) "channel bindings"
facility, and imposes requirements on future GSS-API mechanisms and
programming language bindings of the GSS-API.
"GSS-API Naming Extensions", Nicolas Williams, Leif Johansson, 13-Jul-08,
<draft-ietf-kitten-gssapi-naming-exts-03.txt>
The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization. This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.
Kerberos (krb-wg)
-----------------
"Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
Referrals", Kenneth Raeburn, Larry Zhu, 14-Jul-08,
<draft-ietf-krb-wg-kerberos-referrals-11.txt>
The memo documents a method for a Kerberos Key Distribution Center
(KDC) to respond to client requests for Kerberos tickets when the
client does not have detailed configuration information on the realms
of users or services. The KDC will handle requests for principals in
other realms by returning either a referral error or a cross-realm
TGT to another realm on the referral path. The clients will use this
referral information to reach the realm of the target principal and
then receive the ticket.
"Kerberos Set/Change Key/Password Protocol Version 2", Nicolas Williams,
3-Nov-08, <draft-ietf-krb-wg-kerberos-set-passwd-08.txt>
This document specifies an extensible protocol for setting keys and
changing the passwords of Kerberos V principals.
"A Generalized Framework for Kerberos Pre-Authentication", Larry Zhu, Sam
Hartman, 13-Jul-08, <draft-ietf-krb-wg-preauth-framework-08.txt>
Kerberos is a protocol for verifying the identity of principals
(e.g., a workstation user or a network server) on an open network.
The Kerberos protocol provides a mechanism called pre-authentication
for proving the identity of a principal and for better protecting the
long-term secret of the principal.
This document describes a model for Kerberos pre-authentication
mechanisms. The model describes what state in the Kerberos request a
pre-authentication mechanism is likely to change. It also describes
how multiple pre-authentication mechanisms used in the same request
will interact.
This document also provides common tools needed by multiple pre-
authentication mechanisms. One of these tools is a secure channel
between the client and the KDC with a reply key delivery mechanism;
this secure channel can be used to protect the authentication
exchange thus eliminate offline dictionary attacks. With these
tools, it is relatively straightforward to chain multiple
authentication mechanisms, utilize a different key management system,
or support a new key agreement algorithm.
"Anonymity Support for Kerberos", Larry Zhu, Paul Leach, 10-Oct-08,
<draft-ietf-krb-wg-anon-10.txt>
This document defines extensions to the Kerberos protocol to allow a
Kerberos client to securely communicate with a Kerberos application
service without revealing its identity, or without revealing more
than its Kerberos realm. It also defines extensions which allow a
Kerberos client to obtain anonymous credentials without revealing its
identity to the Kerberos Key Distribution Center (KDC). This
document updates RFC 4120, RFC 4121, and RFC 4556.
"Additional Kerberos Naming Constraints", Larry Zhu, 12-Aug-08,
<draft-ietf-krb-wg-naming-07.txt>
This document defines new naming constraints for well-known Kerberos
principal name and well-known Kerberos realm names.
"PK-INIT algorithm agility", Love Astrand, Larry Zhu, 5-Aug-08,
<draft-ietf-krb-wg-pkinit-alg-agility-04.txt>
The PK-INIT defined in RFC 4556 is examined and updated to remove
protocol structures tied to specific cryptographic algorithms. The
affinity to SHA-1 as the checksum algorithm in the authentication
request is analyzed. The PK-INIT key derivation function is made
negotiable, the digest algorithms for signing the pre-authentication
data and the client's X.509 certificates are made discoverable.
These changes provide protection preemptively against vulnerabilities
discovered in the future against any specific cryptographic
algorithm, and allow incremental deployment of newer algorithms.
"Kerberos Version 5 GSS-API Channel Binding Hash Agility", Shawn Emery,
3-Nov-08, <draft-ietf-krb-wg-gss-cb-hash-agility-05.txt>
Currently, channel bindings are implemented using a MD5 hash in the
Kerberos Version 5 Generic Security Services Application Programming
Interface (GSS-API) mechanism [RFC4121]. This document updates
RFC4121 to allow channel bindings using algorithms negotiated based
on Kerberos crypto framework as defined in RFC3961. In addition,
because this update makes use of the last extensible field in the
Kerberos client-server exchange message, extensions are defined to
allow future protocol extensions.
"Problem statement on the cross-realm operation of Kerberos", Shoichi Sakane,
30-Oct-08, <draft-ietf-krb-wg-cross-problem-statement-03.txt>
There are some issues when the cross-realm operation of the Kerberos
Version 5 [RFC4120] is employed into actual specific systems. This
document describes some examples of actual systems, and lists
requirements and restriction of the operation in such system. Then
it describes issues when we apply the cross-realm operation to such
system.
"OTP Pre-authentication", Gareth Richards, 15-Sep-08,
<draft-ietf-krb-wg-otp-preauth-08.txt>
The Kerberos protocol provides a framework authenticating a client
using the exchange of pre-authentication data. This document
describes the use of this framework to carry out One Time Password
(OTP) authentication.
"Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API
(IAKERB)", Larry Zhu, Jeffrey Altman, 3-Nov-08,
<draft-ietf-krb-wg-iakerb-01.txt>
This document defines extensions to the Kerberos protocol and the
GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
exchange messages with the KDC using the GSS-API acceptor as the
proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
With these extensions a client can obtain Kerberos tickets for
services where the KDC is not accessible to the client, but is
accessible to the application server.
"An information model for Kerberos version 5", Leif Johansson, 2-Nov-08,
<draft-ietf-krb-wg-kdc-model-03.txt>
This document describes an information model for Kerberos version 5
from the point of view of an administrative service. There is no
standard for administrating a kerberos 5 KDC. This document
describes the services exposed by an administrative interface to a
KDC.
Layer 1 Virtual Private Networks (l1vpn)
----------------------------------------
"OSPFv3 Based Layer 1 VPN Auto-Discovery", Lou Berger, 8-Aug-08,
<draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt>
This document defines an Open Shortest Path First (OSPF) version 3
based Layer-1 Virtual Private Network (L1VPN) auto-discovery
mechanism. This document parallels the existing OSPF version 2 L1VPN
auto-discovery mechanism. The notable functional difference is the
support of IPv6.
Layer Two Tunneling Protocol Extensions (l2tpext)
-------------------------------------------------
"PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos
Pignataro, 10-Jul-08, <draft-ietf-l2tpext-l2tp-ppp-08.txt>
This document describes the use of "version 3" of Layer Two Tunneling
Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets.
This document defines the control protocol and encapsulation
specifics for tunneling PPP over L2TPv3, and is a companion document
to the L2TPv3 base specification.
"Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur,
Alexander Vainshtein, 29-Oct-08, <draft-ietf-l2tpext-tdm-06.txt>
This document defines extensions to the Layer Two Tunneling Protocol
(L2TP) for support of structure-agnostic and structure-aware TDM
pseudowires.
"L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro,
19-Nov-08, <draft-ietf-l2tpext-circuit-status-extensions-01.txt>
This document defines additional Layer 2 Tunneling Protocol Version 3
(L2TPv3) bit values to be used within the "Circuit Status" Attribute
Value Pair (AVP) to communicate more granular error states for Access
Circuits and Pseudowires. It also deprecates the use of the New bit
in the "Circuit Status" AVP, updating RFC3931.
Layer 2 Virtual Private Networks (l2vpn)
----------------------------------------
"Provisioning, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 5-May-06,
<draft-ietf-l2vpn-signaling-08.txt>
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).
"L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, Simon
Delord, Philippe Niger, 14-Jul-08, <draft-ietf-l2vpn-oam-req-frmk-10.txt>
This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN)
tunnels. The requirements are intended to identify OAM requirement
for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if
L2VPN services OAM requirements impose specific requirements on PWOAM and/or
PSN OAM, those specific PW and/or PSN OAM requirements are also identified.
"Requirements for Multicast Support in Virtual Private LAN Services", Yuji
Kamite, Yuichiro Wada, Yetik Serbest, Thomas Morin, Luyuan Fang, 5-Aug-08,
<draft-ietf-l2vpn-vpls-mcast-reqts-06.txt>
This document provides functional requirements for network solutions
that support multicast over Virtual Private LAN Service (VPLS). It
specifies requirements both from the end user and service provider
standpoints. It is intended that potential solutions will use these
requirements as guidelines.
"Multicast in VPLS", Rahul Aggarwal, Yuji Kamite, Luyuan Fang, Yakov Rekhter,
Intellectual Property, 2-Jun-08, <draft-ietf-l2vpn-vpls-mcast-04.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 VPLSs are also described.
"VPLS Interoperability with CE Bridges", Dinesh Mohan, Ali Sajassi,
29-Sep-08, <draft-ietf-l2vpn-vpls-bridge-interop-04.txt>
One of the main motivations behind VPLS is its ability to provide
connectivity not only among customer routers and servers/hosts but
also among customer IEEE bridges. VPLS is expected to deliver the
same level of service that current enterprise users are accustomed
to from their own enterprise bridged networks or their Ethernet
Service Providers.
When CE devices are IEEE bridges, then there are certain issues and
challenges that need to be accounted for in a VPLS network. The
majority of these issues have currently been addressed in the IEEE
802.1ad standard for provider bridges and they can be leveraged for
VPLS networks. This draft extends the PE model described in RFC 4664 based
on IEEE 802.1ad bridge module and illustrates a clear demarcation between
IEEE bridge module and IETF LAN emulation module. By doing so, it describes
that the majority of interoperability issues with CE bridges can be delegated
to 802.1ad bridge module, thus removing the burden on IETF LAN emulation
module within a VPLS PE.
"Virtual Private Lan Services (VPLS) Management Information Base", Rohit
Mediratta, Thomas Nadeau, Kiran Koushik, 15-Jul-08,
<draft-ietf-l2vpn-vpls-mib-02.txt>
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 Virtual Private LAN services. It needs to be used
in conjunction with Pseudo Wire (PW) Management Information Base
[PWE3-PW-MIB].
Layer 3 Virtual Private Networks (l3vpn)
----------------------------------------
"Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai,
Thomas Morin, Yakov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa,
10-Jul-08, <draft-ietf-l3vpn-2547bis-mcast-07.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.
"BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul
Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, Intellectual Property,
16-Jun-08, <draft-ietf-l3vpn-2547bis-mcast-bgp-05.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].
"Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS
IP-VPN", Kenji Kumaki, Yuji Kamite, Raymond Zhang, 3-Nov-08,
<draft-ietf-l3vpn-e2e-rsvp-te-reqts-02.txt>
Some service providers want to build a service which guarantees QoS
or bandwidth from a local CE to a remote CE through the network.
Today, customers expect to run triple play services through BGP/MPLS
IP-VPNs. As a result, their requirements for end-to-end QoS of
applications are increasing. Depending on the application (e.g.,
voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end
native RSVP path and/or an end-to-end MPLS TE LSP are required, and
they need to meet some constraints.
This document describes service provider requirements for supporting
customer RSVP and RSVP-TE over a BGP/MPLS VPN.
"Four-octet AS Specific BGP Extended Community", Yakov Rekhter, Srihari
Sangli, Dan Tappan, 27-Oct-08,
<draft-ietf-l3vpn-as4octet-ext-community-01.txt>
This document defines a new type of a BGP extended community - four-
octet AS specific extended community. This community allows to carry
4 octet autonomous system numbers.
"IPv6 Address Specific BGP Extended Communities Attribute", Yakov Rekhter,
29-Sep-08, <draft-ietf-l3vpn-v6-ext-communities-00.txt>
Current specifications of BGP Extended Communities [BGP-EXTCOMM]
support IPv4 Address Specific Extended Community, but do not support
IPv6 Address Specific Extended Community. The lack of IPv6 Address
Specific Extended Community may be a problem when an application uses
IPv4 Address Specific Extended Community, and one wants to use this
application in a pure IPv6 environment. This document defines a new
BGP attribute, IPv6 Address Specific Extended Community that
addresses this problem. The IPv6 Address Specific Extended Community
is similar to the IPv4 Address Specific Extended Community, except
that it carries an IPv6 address rather than an IPv4 address.
"BGP ACCEPT_OWN Standards Action Community Attribute", James Uttaro, Pradosh
Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property,
5-Oct-08, <draft-ietf-l3vpn-acceptown-community-00.txt>
Under certain conditions it is desirable for a BGP route reflector to
be able to modify the Route Target list of a VPN route that is
distributed by the route reflector, enabling the route reflector to
control how a route originated within one VRF is imported into other
VRFs. This technique works effectively as long as the VRF that
exports the route is not on the same PE as the VRF(s) that import the
route. However, due to the constraints of the BGP protocol, it does
not work if the two are on the same PE.
This document describes a modification to the BGP protocol allowing
this technique to work when the VRFs are on the same PE, allowing the
technique to be used in a standard manner throughout an autonomous
system.
"OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff
Doyle, Emre Ertekin, Michael Lundberg, 2-Nov-08,
<draft-ietf-l3vpn-ospfv3-pece-01.txt>
Many Service Providers (SPs) offer the 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.
"Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas
Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil
Bitar, 18-Nov-08, <draft-ietf-l3vpn-mvpn-considerations-00.txt>
The current proposal for multicast in BGP/MPLS includes multiple
alternative mechanisms for some of the required building blocks of
the solution. The aim of this document is to leverage previously
documented requirements to identify the key elements and help move
forward solution design, toward the definition of a standard having a
well defined set of mandatory procedures. The different proposed
alternative mechanisms are examined in the light of requirements
identified for multicast in L3VPNs, and suggestions are made about
which of these mechanisms standardization should favor. Issues
related to existing deployments of early implementations are also
addressed.
Enhancements to Internet email to Support Diverse Service Environments (lemonade)
---------------------------------------------------------------------------------
"Lemonade Notifications Architecture", Randall Gellens, Stephane Maes,
8-Jul-08, <draft-ietf-lemonade-notifications-10.txt>
This document discusses how to provide notification and filtering
mechanisms to mail stores to meet Lemonade goals.
This document also discusses the use of server to server
notifications, and how server to server notifications fit into an
architecture which provides server to client notifications.
Gellens
[page 1]
Expires January 2009
Internet Draft
Lemonade Notifications Architecture
July 2008
"The Lemonade Profile", Dave Cridland, Alexey Melnikov, Stephane Maes,
30-Sep-08, <draft-ietf-lemonade-profile-bis-11.txt>
This document describes a profile (a set of required extensions,
restrictions and usage modes) of the IMAP and mail submission
protocols. This profile allows clients (especially those that are
constrained in memory, bandwidth, processing power, or other areas)
to efficiently use IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to
download and upload the mail, to optimize submission and to
efficiently resynchronize in case of loss of connectivity with the
server.
The Lemonade profile relies upon several extensions to IMAP and Mail
Submission protocols.
"Internet Message Store Events", Randall Gellens, Chris Newman, 2-Nov-08,
<draft-ietf-lemonade-msgevent-07.txt>
One of the missing features in the existing Internet mail and
messaging standards is a facility for server-to-server and server-to-
client event notifications related to message store events. As the
scope of Internet mail expands to support more diverse media (such as
voice mail), devices (such as cell phones) and to provide rich
interactions with other services (such as web portals and legal
compliance systems), the need for an interoperable notification
system increases. This document attempts to enumerate the types of
events which interest real-world consumers of such a system.
This document describes events and event parameters which are useful
for several cases, including notification to administrative systems
and end users. This is not intended as a replacement for a message
access facility such as IMAP.
"Streaming Internet Messaging Attachments", Neil Cook, 26-Sep-08,
<draft-ietf-lemonade-streaming-07.txt>
This document describes a method for streaming multimedia attachments
received by a resource constrained and/or mobile device from an IMAP
server. It allows such clients, which often have limits in storage
space and bandwidth, to play video and audio e-mail content.
The document describes a profile for making use of the IMAP URLAUTH
extension (RFC 4467), the Network Announcement SIP Media Service (RFC
4240), and the Media Server Control Markup Language (RFC 5022).
"IMAP4 extension for named searches (filters)", Alexey Melnikov, Curtis King,
22-Sep-08, <draft-melnikov-imapext-filters-06.txt>
The document defines a way to persistently store named IMAP (RFC
3501) searches on the server. Such named searches can be
subsequently referenced in a SEARCH or any other command that accepts
a search criteria as a parameter.
"The IMAP NOTIFY Extension", Arnt Gulbrandsen, Alexey Melnikov, Curtis King,
19-Aug-08, <draft-ietf-lemonade-imap-notify-07.txt>
This document defines an IMAP extension which allows a client to
request specific kinds of unsolicited notifications for specified
mailboxes, such as messages being added to or deleted from
mailboxes.
[[Add Updates: RFC-CONTEXT to the headers]]
"LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email
(MEM) using Internet Mail", Eric Burger, Glenn Parsons, 3-Nov-08,
<draft-ietf-lemonade-architecture-04.txt>
This document specifies the architecture for mobile email, as
described by the Open Mobile Alliance (OMA), using Internet Mail
protocols. This architecture was an important consideration for much
of the work of the LEMONADE (Enhancements to Internet email to
Support Diverse Service Environments) work group in the IETF. This
document also describes how the LEMONADE architecture meets the OMA's
requirements for their Mobile Email (MEM) service.
"Extended URLFETCH for binary and converted parts", Dave Cridland, 4-Sep-08,
<draft-cridland-urlfetch-binary-03.txt>
The URLFETCH command defined as part of URLAUTH provides a mechanism
for third-parties to gain access to data held within messages in a
user's private store, however, this data is sent verbatim, which is
not suitable for a number of applications. This memo specifies a
method for obtaining data in forms suitable for non-mail
applications.
"IMAP4 Extensions for Quick Mailbox Resynchronization", Alexey Melnikov, Dave
Cridland, Corby Wilson, 19-Oct-08, <draft-ietf-lemonade-5162bis-00.txt>
This document defines an IMAP4 extension, which gives an IMAP client
the ability to quickly resynchronize any previously opened mailbox as
part of the SELECT command, without the need for server-side state or
additional client round-trips. This extension also introduces a new
response that allows for a more compact representation of a list of
expunged messages (and always includes the Unique Identifiers (UIDs)
expunged).
Long-Term Archive and Notary Services (ltans)
---------------------------------------------
"Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, Peter Sylvester,
Carl Wallace, 2-Nov-08, <draft-ietf-ltans-ltap-07.txt>
This document describes a service operated as a trusted third party
to securely archive electronic documents called a long-term archive
service (LTA). We describe an architecture framework and a protocol
allowing clients to interact with such a service. Bindings to
concrete transport and security protocol layers are given.
"Data Structure for the Security Suitability of Cryptographic Algorithms
(DSSC)", Thomas Kunz, Susanne Okunick, Ulrich Pordesch, 3-Nov-08,
<draft-ietf-ltans-dssc-05.txt>
In many application areas it must be possible to prove the existence
and integrity of digital signed data. This proof depends on the
security suitability of the cryptographic algorithms used to generate
or verify the digital signature. Because algorithms can become weak
over the years, it is necessary to periodically evaluate their
security suitability. When signing or verifying data, these
evaluations must be considered. This document specifies a data
structure that enables automated analysis of the security suitability
of cryptographic algorithms.
Language Tag Registry Update (ltru)
-----------------------------------
"Tags for Identifying Languages", Addison Phillips, Mark Davis, 31-Oct-08,
<draft-ietf-ltru-4646bis-18.txt>
This document describes the structure, content, construction, and
semantics of language tags for use in cases where it is desirable to
indicate the language used in an information object. It also
describes how to register values for use in language tags and the
creation of user-defined extensions for private interchange.
"Update to the Language Subtag Registry", Doug Ewell, 1-Nov-08,
<draft-ietf-ltru-4645bis-07.txt>
This memo defines the procedure used to update the IANA Language
Subtag Registry in conjunction with the publication of RFC 4646bis
[RFC EDITOR NOTE: replace with actual RFC number], for use in forming
tags for identifying languages. As an Internet-Draft, it also
contained a complete replacement of the contents of the Registry to
be used by IANA in updating it. To prevent confusion, this material
was removed before publication.
Multicast & Anycast Group Membership (magma)
--------------------------------------------
"Multicast Group Membership Discovery MIB", Julian Chesterfield, 16-Sep-08,
<draft-ietf-magma-mgmd-mib-12.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing the Internet
Group Management Protocol (IGMP) and the Multicast Listener
Discovery (MLD) protocol.
Mobile Ad-hoc Networks (manet)
------------------------------
"Dynamic MANET On-demand (DYMO) Routing", Ian Chakeres, Charles Perkins,
17-Nov-08, <draft-ietf-manet-dymo-15.txt>
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.
"Simplified Multicast Forwarding for MANET", Joseph Macker, SMF Team,
3-Nov-08, <draft-ietf-manet-smf-08.txt>
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 specifies
techniques for multicast duplicate packet detection (DPD) to assist
the forwarding process. SMF also specifies DPD maintenance and
checking operations for with both IPv4 and IPv6. SMF also specifies
the optional use of reduced relay sets for efficient MANET multicast
data distribution within a mesh topology. 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.
"The Optimized Link State Routing Protocol version 2", Thomas Clausen,
Christopher Dearlove, Philippe Jacquet, 10-Jul-08,
<draft-ietf-manet-olsrv2-07.txt>
This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol. The protocol embodies an optimization of the
classical link state algorithm tailored to the requirements of a
Mobile Ad hoc NETwork (MANET).
The key optimization in OLSRv2 is that of multipoint relays (MPRs),
providing an efficient mechanism for network-wide broadcast of link
state information (i.e. reducing the cost of performing a network-
wide link state broadcast). A secondary optimization is that OLSRv2
employs partial link state information; each node maintains
information about all destinations, but only a subset of links.
Consequently, only selected nodes flood link state advertisements
(thus reducing the number of network-wide link state broadcasts) and
these advertisements contain only a subset of links (thus reducing
the size of network-wide link state broadcasts). The partial link
state information thus obtained still allows each OLSRv2 node to at
all times maintain optimal (in terms of number of hops) routes to all
destinations in the network.
OLSRv2 imposes minimum requirements on the network by not requiring
sequenced or reliable transmission of control traffic. Furthermore,
the only interaction between OLSRv2 and the IP stack is routing table
management.
OLSRv2 is particularly suitable for large and dense networks as the
technique of MPRs works best in this context.
"Generalized MANET Packet/Message Format", Thomas Clausen, Christopher
Dearlove, Justin Dean, Cedric Adjih, 18-Nov-08,
<draft-ietf-manet-packetbb-17.txt>
This document specifies a packet format capable of carrying multiple
messages that may be used by mobile ad hoc network routing protocols.
"MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher
Dearlove, Justin Dean, 10-Jul-08, <draft-ietf-manet-nhdp-07.txt>
This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
"IANA Allocations for MANET Protocols", Ian Chakeres, 18-Nov-07,
<draft-ietf-manet-iana-07.txt>
This document enumerates several common IANA allocations for use by
MANET protocols. The following well-known numbers are required: a
UDP port number, an IP protocol number, and a link-local multicast
group address.
"Representing multi-value time in MANETs", Thomas Clausen, Christopher
Dearlove, 26-Sep-08, <draft-ietf-manet-timetlv-08.txt>
This document describes a general and flexible TLV (type-length-value
structure) for representing time-values, such as an interval or a
duration, using the generalized MANET packet/message format. It
defines two message and two address block TLVs for representing
validity and interval times for MANET routing protocols.
"Definition of Managed Objects for the DYMO Manet Routing Protocol", Sean
Harnedy, Robert Cole, Ian Chakeres, 3-Nov-08,
<draft-ietf-manet-dymo-mib-01.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the
DYMO routing process. The DYMO MIB also reports state information,
performance metrics, and notifications. In addition to
configuration, this additional state and performance information is
useful to management stations troubleshooting routing problems.
MBONE Deployment (mboned)
-------------------------
"Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, Mohit
Talwar, Amit Aggarwal, Lorenzo Vicisano, Tom Pusateri, 27-Jun-08,
<draft-ietf-mboned-auto-multicast-09.txt>
Automatic Multicast Tunneling (AMT) allows multicast communication
amongst isolated multicast-enabled sites or hosts, attached to a
network which has no native multicast support. It also enables them
to exchange multicast traffic with the native multicast
infrastructure and does not require any manual configuration. AMT
uses an encapsulation interface so that no changes to a host stack or
applications are required, all protocols (not just UDP) are handled,
and there is no additional overhead in core routers.
"IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton,
Dave Meyer, 3-Nov-08, <draft-ietf-mboned-rfc3171bis-04.txt>
This document obsoletes RFC 3171. It provides guidance for the
Internet Assigned Numbers Authority (IANA) in assigning IPv4
multicast addresses.
"Requirements for Multicast AAA coordinated between Content Provider(s) and
Network Service Provider(s)", Haixiang He, 20-Jun-08,
<draft-ietf-mboned-maccnt-req-06.txt>
This memo presents requirements in the area of accounting and
access control for IP multicasting. The scope of the requirements
is limited to cases that Authentication, Accounting and
Authorization (AAA) functions are coordinated between Content
Provider(s) and Network Service Provider(s). General requirements
for accounting and admission control capabilities including
quality-of-service (QoS) related issues are listed. This memo
assumes that these capabilities can be realized by functions
implemented at edges of a network based on IGMP or MLD. Finally,
cases for Content Delivery Services (CDS) are described as
application examples which could benefit from multicasting
accounting and access control capabilities as described in this
memo.
This memo defines requirements related to AAA issues for multi-
entity provider models in which the network service provider and
content provider cooperate to provide CDS and various related AAA
functions for purposes such as protecting and accounting for the
access to content and network resources. The requirements are
generally not relevant to cases in which there is not a reason to
share AAA functions between separate entities.
"AAA and Admission Control Framework for Multicasting", Hiroaki Satou,
2-Jul-08, <draft-ietf-mboned-multiaaa-framework-07.txt>
IP multicast-based services, such as TV broadcasting or
videoconferencing raise the issue of making sure that
potential customers are fully entitled to access the
corresponding contents. There is indeed a need for service
and content providers to identify users (if not
authenticate, especially within the context of enforcing
electronic payment schemes) and to retrieve statistical
information for accounting purposes, as far as content and
network usage are concerned. This memo describes the
framework for specifying the Authorization, Authentication
and Accounting (AAA) capabilities that could be activated
within the context of the deployment and the operation of
IP multicast-based services. This framework addresses the
requirements presented in "Requirements for Accounting,
Authentication and Authorization in Well Managed IP
Multicasting Services" [I-D.mboned-maccnt-req]. The memo
provides a basic AAA enabled model as well as an extended
fully enabled model with resource and admission control
coordination.
"Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, Wei Cao, Hitoshi Asaeda,
6-Sep-08, <draft-ietf-mboned-lightweight-igmpv3-mldv2-04.txt>
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
IGMPv3 and MLDv2. The interoperability with the full versions and
the previous versions of IGMP and MLD is also taken into account.
"Multicast Ping Protocol", Stig Venaas, 3-Nov-08,
<draft-ietf-mboned-ssmping-06.txt>
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 like
multicast tree setup time etc. This protocol is based on an
implementation of tools called ssmping and asmping.
"Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda,
Tatuya Jinmei, Bill Fenner, Stephen Casner, 3-Nov-08,
<draft-ietf-mboned-mtrace-v2-02.txt>
This document describes the IP multicast traceroute facility. Unlike
unicast traceroute, multicast traceroute requires special
implementations on the part of routers. This specification describes
the required functionality in multicast routers, as well as how
management applications can use the router functionality.
"Requirements for IP Multicast Session Announcement in the Internet", Hitoshi
Asaeda, Vincent Roca, 27-Oct-08,
<draft-ietf-mboned-session-announcement-req-00.txt>
The Session Announcement Protocol (SAP) [3] was used to announce
information for all available multicast sessions to the prospective
receiver in an experimental network. It is useful and easy to use,
but difficult to control the SAP message transmission in a wide area
network. This document describes the several major limitations SAP
has and the requirements for multicast session announcement in the
global Internet.
Media Server Control (mediactrl)
--------------------------------
"Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott
McGlashan, 31-Oct-08, <draft-ietf-mediactrl-sip-control-framework-06.txt>
This document describes a Framework and protocol for application
deployment where the application programming logic and processing are
distributed. This implies that application programming logic can
seamlessly gain access to appropriate resources that are not co-
located on the same physical network entity. The framework uses the
Session Initiation Protocol (SIP) to establish an application-level
control mechanism between application servers and associated external
servers such as media servers.
The motivation for the creation of this Framework is to provide an
interface suitable to meet the requirements of a distributed,
centralized conference system, as defined by the IETF. It is not,
however, limited to this scope and it is envisioned that this generic
Framework will be used for a wide variety of de-coupled control
architectures between network entities.
"An Architectural Framework for Media Server Control", Tim Melanchuk,
17-Apr-08, <draft-ietf-mediactrl-architecture-03.txt>
This document describes an Architectural Framework for Media Server
Control. The primary focus will be to define logical entities that
exist within the context of Media Server control, and define the
appropriate naming conventions and interactions between them.
"SIP Interface to VoiceXML Media Services", Dave Burke, Mark Scott, 8-Jul-08,
<draft-ietf-mediactrl-vxml-02.txt>
This document describes a SIP interface to VoiceXML media services.
Commonly, application servers controlling media servers use this
protocol for pure VoiceXML processing capabilities. This protocol is
an adjunct to the full MEDIACTRL protocol and packages mechanism.Comments
Please send comments on this draft to the MEDIACTRL mail list,
mediactrl@ietf.org.
"An Interactive Voice Response (IVR) Control Package for the Media Control
Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 3-Nov-08,
<draft-ietf-mediactrl-ivr-control-package-02.txt>
This document defines a Media Control Channel Framework Package for
Interactive Voice Response (IVR) dialog interaction on media
connections and conferences. The package defines dialog management
request elements for preparing, starting and terminating dialog
interactions, as well as associated responses and notifications.
Dialog interactions are specified in a dialog language. This package
defines a lightweight IVR dialog language (supporting prompt
playback, runtime controls, DTMF collect and media recording) and
allows other dialog languages to be used. The package also defines
elements for auditing package capabilities and IVR dialogs.
"A Mixer Control Package for the Media Control Channel Framework", Tim
Melanchuk, Scott McGlashan, Chris Boulton, 3-Nov-08,
<draft-ietf-mediactrl-mixer-control-package-02.txt>
This document defines a Mixer Control Package for the Media Control
Channel Framework. This Control Package aims to fulfill Conferencing
requirements using the SIP Control Framework.
Mobility EXTensions for IPv6 (mext)
-----------------------------------
"Multiple Care-of Addresses Registration", Ryuji Wakikawa, Vijay Devarapalli,
Thierry Ernst, Kenichi Nagami, 3-Nov-08,
<draft-ietf-monami6-multiplecoa-10.txt>
According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through
multiple accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses. This
document proposes extensions to the Mobile IPv6 protocol to register
and use multiple care-of addresses. The extensions proposed in this
document can be used by Mobile Routers using the NEMO (Network
Mobility) Basic Support protocol as well.
"Home Agent Reliability Protocol", Ryuji Wakikawa, 14-Jul-08,
<draft-ietf-mip6-hareliability-04.txt>
The home agent can be a single point of failure when Mobile IPv6 is
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 a mechanism of home
agent failure detection, home agent state transfer, and home agent
switching for home agent redundancy and reliability.
"RADIUS Mobile IPv6 Support", Avi Lior, Kuntal Chowdhury, Hannes Tschofenig,
3-Nov-08, <draft-ietf-mip6-radius-06.txt>
This document defines new attributes to facilitate Mobile IPv6
operations using RADIUS infrastructure. The operations include
bootstrapping of information required by the Mobile Node and the
interface between the Network Access Server, Home Agent and the
RADIUS server used to assist MIP6 operations.
"AAA Goals for Mobile IPv6", Gerardo Giaretta, Ivano Guardini, Elena Demaria,
Julien Bournelle, Rafa Lopez, 2-May-08, <draft-ietf-mext-aaa-ha-goals-01.txt>
In commercial and enterprise deployments Mobile IPv6 can be a service
offered by a Mobility Services Provider (MSP). In this case all
protocol operations may need to be explicitly authorized and traced,
requiring the interaction between Mobile IPv6 and the AAA
infrastructure. Integrating the AAA infrastructure (e.g. NAS and
AAA server) offers also a solution component for Mobile IPv6
bootstrapping. This document describes various scenarios where a AAA
interface for Mobile IPv6 is required. Additionally, it lists design
goals and requirements for such an interface.
"Mobile IPv6 Support for Dual Stack Hosts and Routers", Hesham Soliman,
3-Nov-08, <draft-ietf-mext-nemo-v4traversal-06.txt>
The current Mobile IPv6 and NEMO specifications support IPv6 only.
This specification extends those standards to allow the registration
of IPv4 addresses and prefixes, respectively, and the transport of
both IPv4 and IPv6 packets over the tunnel to the home agent. This
specification also allows the Mobile Node to roam over both IPv6 and
IPv4, including the case where Network Address Translation is present
on the path between the mobile node and its home agent.
"NEMO Management Information Base", Sri Gundavelli, Glenn Mansfield, Kazuhide
Koide, Kenichi Nagami, 20-Nov-08, <draft-ietf-mext-nemo-mib-02.txt>
This memo defines a portion of the Management Information Base (MIB),
the network mobility support (NEMO) MIB, for use with network
management protocols in the Internet community. In particular, the
NEMO MIB will be used to monitor and control a Mobile IPv6 node with
NEMO functionality.
"Automotive Industry Requirements for NEMO Route Optimization", Roberto
Baldessari, Thierry Ernst, Andreas Festag, Massimiliano Lenardi, 14-Jul-08,
<draft-ietf-mext-nemo-ro-automotive-req-01.txt>
This document specifies requirements for NEMO Route Optimization
techniques as identified by the automotive industry. Requirements
are gathered from the Car2Car Communication Consortium and ISO
Technical Committee 204 Working Group 16 (CALM).
"Mobility Support in IPv6", David Johnson, Charles Perkins, Jari Arkko,
1-Oct-08, <draft-ietf-mext-rfc3775bis-02.txt>
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.
"DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, Francis
Dupont, Wassim Haddad, 3-Nov-08, <draft-ietf-mext-nemo-pd-01.txt>
One aspect of network mobility support is the assignment of a prefix
or prefixes to a Mobile Router (MR) for use on the links in the
Mobile Network. DHCPv6 prefix delegation can be used for this
configuration task.
"Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri
Gundavelli, Kuntal Chowdhury, Parviz Yegani, 28-Aug-08,
<draft-ietf-mext-binding-revocation-01.txt>
This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources. These
semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions. This mechanism
allows the mobility entity which initiates the revocation procedure
to request its corresponding one to terminate either one, multiple or
all specified binding cache entries.
"Mobile IPv6 Generic Signaling Message", Brian Haley, Sri Gundavelli,
14-Aug-08, <draft-ietf-mext-generic-signaling-message-00.txt>
This document specifies two new Mobility Header message types that
allow Mobile IPv6 entities to send and receive generic signaling
messages.
Haley
Expires - January 2008
[page 1]
Mobile IPv6 Generic Signaling Message
August 2008
"Guidelines for firewall administrators regarding MIPv6 traffic", Suresh
Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 10-Oct-08,
<draft-ietf-mext-firewall-admin-00.txt>
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
signaling and data messages to pass through. For other scenarios,
the support of additional mechanisms to create pinholes required for
MIPv6 will be necessary. This document assumes that the firewalls in
question include some kind of stateful packet filtering capability.
"Guidelines for firewall vendors regarding MIPv6 traffic", Suresh Krishnan,
Yaron Sheffer, Niklas Steinleitner, Gabor Bajko, 10-Oct-08,
<draft-ietf-mext-firewall-vendor-00.txt>
This document presents some recommendations for firewall vendors to
help them implement their firewalls in a way that allows Mobile IPv6
signaling and data messages to pass through. This document describes
how to implement stateful packet filtering capability for MIPv6.
Mobility for IPv4 (mip4)
------------------------
"The Definitions of Managed Objects for IP Mobility Support using SMIv2,
revised", Kent Leung, Ravindra Rathi, Hans Sjostrand, 7-Aug-08,
<draft-ietf-mip4-rfc2006bis-05.txt>
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
Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.
"IP Mobility Support for IPv4, revised", Charles Perkins, 2-Nov-08,
<draft-ietf-mip4-rfc3344bis-07.txt>
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to mobile nodes in the 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 its current point of
attachment to the Internet. The protocol provides for registering
the care-of address with a home agent. The home agent sends
datagrams destined for the mobile node through a tunnel to the
care-of address. After arriving at the end of the tunnel, each
datagram is then delivered to the mobile node.
"Dual Stack Mobile IPv4", George Tsirtsis, Vincent Park, Hesham Soliman,
18-Nov-08, <draft-ietf-mip4-dsmipv4-08.txt>
This specification provides IPv6 extensions to the Mobile IPv4
protocol. The extensions allow a dual stack node to use IPv4 and
IPv6 home addresses as well as to move between IPv4 and dual stack
network infrastructures.
"Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz,
Vijay Devarapalli, Sri Gundavelli, Brian Haley, 3-Nov-08,
<draft-ietf-mip4-generic-notification-message-07.txt>
This document specifies protocol enhancements that allow Mobile IPv4
entities to send and receive explicit notification messages using a
new Mobile IPv4 message type designed for this purpose.
"Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Vidya
Narayanan, Kent Leung, 29-Aug-08, <draft-ietf-mip4-nemov4-dynamic-02.txt>
The base NEMOv4 specification defines extensions to Mobile IPv4 for
mobile networks. This specification defines a dynamic prefix
allocation mechanism.
"The Definitions of Managed Objects for Mobile IP UDP Tunneling", Hans
Sjostrand, 11-Aug-08, <draft-ietf-mip4-udptunnel-mib-01.txt>
This memo defines the Management Information Base (MIB) for use with
network management protocols in TCP/IP-based internets. In
particular, it describes managed objects used for managing the Mobile
Node, Foreign Agent and Home Agent when Mobile IP Traversal of
Network Address Translation (NAT) Devices are used.
Mobility for IPv6 (mip6)
------------------------
"Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont,
Jean-Michel Combes, 25-Aug-08, <draft-ietf-mip6-cn-ipsec-08.txt>
Mobile IPv6 uses IPsec to protect signaling between the Mobile Node
and the Home Agent. This document defines how IPsec can be used
between the Mobile Node and Correspondent Nodes for Home Address
Option validation and protection of mobility signaling for Route
Optimization. The configuration details for IPsec and IKE are also
provided.
"Why Authentication Data suboption is needed for MIP6", Basavaraj Patil,
Gopal Dommety, 2-Nov-08, <draft-ietf-mip6-whyauthdataoption-07.txt>
Mobile IPv6 defines a set of signaling messages that enable the
mobile node (MN) to authenticate and perform registration with its
home agent (HA). These authentication signaling messages between the
mobile node and home agent are secured by an IPsec SA that is
established between the MN and HA. The MIP6 working group has
specified a mechanism to secure the binding update and binding
acknowledgement messages using an authentication option, similar to
the authentication option in Mobile IPv4, carried within the
signaling messages that are exchanged between the MN and HA to
establish a binding. This document provides the justifications as to
why the authentication option mechanism was needed for Mobile IPv6
deployment in certain environments.
"MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper
Yegin, 21-Apr-08, <draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt>
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.
"DHCP Options for Home Information Discovery in MIPv6", Hee-Jin Jang, Alper
Yegin, Kuntal Chowdhury, JinHyeock Choi, 22-May-08,
<draft-ietf-mip6-hiopt-17.txt>
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.
Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop)
--------------------------------------------------------------------------
"IEEE 802.21 Mobility Services Framework Design (MSFD)", Telemaco Melia,
Gabor Bajko, Subir Das, Nada Golmie, Juan Zuniga, 3-Nov-08,
<draft-ietf-mipshop-mstp-solution-09.txt>
This document describes a mobility services framework design (MSFD)
for the IEEE 802.21 Media Independent Handover (MIH) protocol that
addresses identified issues associated with the transport of MIH
messages. The document also describes mechanisms for mobility
service (MoS) discovery and transport layer mechanisms for the
reliable delivery of MIH messages.
"Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE
802.21 Mobility Server (MoS) discovery", Gabor Bajko, Subir Das, 18-Nov-08,
<draft-ietf-mipshop-mos-dhcp-options-08.txt>
This document defines a number of Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) options that contain a list of domain names
or IP addresses that can be mapped to servers providing IEEE 802.21
type of Mobility Services [MSFD]. These Mobility Services are used
to assist an MN in handover preparation (network discovery) and
handover decision (network selection). The services addressed
in this document are the Media Independent Handover Services
defined in [IEEE802.21].
"Locating IEEE 802.21 Mobility Servers using DNS", Gabor Bajko, 20-Oct-08,
<draft-ietf-mipshop-mos-dns-discovery-04.txt>
This document defines application service tags that allow service
location without relying on rigid domain naming conventions, and DNS
procedures for discovering servers which provide IEEE 802.21
[IEEE802.21] defined Mobility Services. Such Mobility Services are
used to assist a Mobile Node (MN) supporting IEEE 802.21
[IEEE802.21], in handover preparation (network discovery) and
handover decision (network selection). The services addressed by
this document are the Media Independent Handover Services defined in
[IEEE802.21].
"Fast Handovers for Proxy Mobile IPv6", Hidetoshi Yokota, Kuntal Chowdhury,
Rajeev Koodli, Basavaraj Patil, Frank Xia, 27-Oct-08,
<draft-ietf-mipshop-pfmipv6-00.txt>
This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
Proxy Mobile IPv6 is used as the mobility management protocol.
Necessary extensions are specified for FMIPv6 to support the scenario
when the mobile node does not have IP mobility functionality and
hence is not involved with either MIPv6 or FMIPv6 operations.
"Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna,
Oliver Blume, 27-Oct-08, <draft-ietf-mipshop-transient-bce-pmipv6-00.txt>
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 for inter-MAG handover optimization. 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.
Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
"Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob
Lanphier, Magnus Westerlund, Martin Stiemerling, 3-Nov-08,
<draft-ietf-mmusic-rfc2326bis-19.txt>
This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326.
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 3550).
"An Network Address Translator (NAT) Traversal mechanism for media controlled
by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund,
Thomas Zeng, 14-Jul-08, <draft-ietf-mmusic-rtsp-nat-07.txt>
This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams setup and controlled
with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
signalling channel, defining the necessary extra RTSP extensions and
procedures.
"Interactive Connectivity Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols", Jonathan Rosenberg,
29-Oct-07, <draft-ietf-mmusic-ice-19.txt>
This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia sessions established with
the offer/answer model. This protocol is called Interactive
Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension,
Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation
Protocol (SIP).
"An Extension to the Session Description Protocol (SDP) for Media Loopback",
Kaynam Hedayat, 4-Aug-08, <draft-ietf-mmusic-media-loopback-09.txt>
The wide deployment of Voice over IP (VoIP), Real-time Text and
Video over IP services has introduced new challenges in managing
and maintaining voice/real-time Text/video quality, reliability,
and overall performance. In particular, media delivery is an area
that needs attention. One method of meeting these challenges is
monitoring the media delivery performance by looping media back to
the transmitter. This is typically referred to as "active
monitoring" of services. Media loopback is especially popular in
ensuring the quality of transport to the edge of a given VoIP,
Real-time Text or Video over IP service. Today in networks that
deliver real-time media, short of running 'ping' and 'traceroute'
to the edge, service providers are left without the necessary tools
to actively monitor, manage, and diagnose quality issues with their
service. The extension defined herein adds new SDP media
attributes which enables establishment of media sessions where the
media is looped back to the transmitter. Such media sessions will
serve as monitoring and troubleshooting tools by providing the
means for measurement of more advanced VoIP, Real-time Text and
Video Over IP performance metrics.
"Connectivity Preconditions for Session Description Protocol Media Streams",
Flemming Andreasen, Gonzalo Camarillo, David Oran, Dan Wing, 24-Oct-08,
<draft-ietf-mmusic-connectivity-precon-05.txt>
This document defines a new connectivity precondition for the Session
Description Protocol (SDP) precondition framework. A connectivity
precondition can be used to delay session establishment or
modification until media stream connectivity has been successfully
verified. The method of verification may vary depending on the type
of transport used for the media. For unreliable datagram transports
such as UDP, verification involves probing the stream with data or
control packets. For reliable connection-oriented transports such as
TCP, verification can be achieved simply by successful connection
establishment or by probing the connection with data or control
packets, depending on the situation.
"TCP Candidates with Interactive Connectivity Establishment (ICE)", Jonathan
Rosenberg, 14-Jul-08, <draft-ietf-mmusic-ice-tcp-07.txt>
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.
"A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File
Transfer", Miguel Garcia, Markus Isomaki, Gonzalo Camarillo, Salvatore
Loreto, Paul Kyzivat, 3-Nov-08, <draft-ietf-mmusic-file-transfer-mech-09.txt>
This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file. The transfer
of one or more files is initiated after a successful negotiation.
The Message Session Relay Protocol (MSRP) is defined as the default
mechanism to actually carry the files between the endpoints. The
conventions on how to use MSRP for file transfer are also provided in
this document.
"SDP Capability Negotiation", Flemming Andreasen, 11-Jul-08,
<draft-ietf-mmusic-sdp-capability-negotiation-09.txt>
The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session
initiation. SDP was not intended to provide capability indication or
capability negotiation, however over the years, SDP has seen
widespread adoption and as a result it has been gradually extended
to provide limited support for these, notably in the form of the
offer/answer model defined in RFC 3264. SDP does not define how to
negotiate one or more alternative transport protocols (e.g. RTP
profiles) or attributes. This makes it difficult to deploy new RTP
profiles such as secure RTP or RTP with RTCP-based feedback,
negotiate use of different security keying mechanisms, etc. It also
presents problems for some forms of media negotiation.
The purpose of this document is to address these shortcomings by
extending SDP with capability negotiation parameters and associated
offer/answer procedures to use those parameters in a backwards
compatible manner.
The document defines a general SDP Capability Negotiation framework.
It also specifies how to provide attributes and transport protocols
as capabilities and negotiate them using the framework. Extensions
for other types of capabilities (e.g. media types and media formats)
may be provided in other documents.
"SDP media capabilities Negotiation", Robert Gilman, Roni Even, Flemming
Andreasen, 14-Jul-08, <draft-ietf-mmusic-sdp-media-capabilities-05.txt>
Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating
transport protocols and attributes. In this document, we extend the
framework by defining media capabilities that can be used to
negotiate media types and their associated parameters. This
extension is designed to map easily to existing and future SDP media
attributes.
"The evaluation of different NAT traversal Techniques for media controlled by
Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng,
11-Jul-08, <draft-ietf-mmusic-rtsp-nat-evaluation-01.txt>
This document describes several NAT traversal techniques that could
be used by RTSP. Each technique includes a description on how it
would be used, the security implications of using it and any other
deployment considerations it has. There are also disussions on how
NAT traversal techniques relates to firewalls and how each technique
can be applied in different use cases. These findings where used
when selecting the NAT traversal for RTSP solution to standardize in
the MMUSIC WG.
"Quality of Service (QoS) Mechanism Selection in the Session Description
Protocol (SDP)", James Polk, Subha Dhesikan, Gonzalo Camarillo, 18-Nov-08,
<draft-ietf-mmusic-qos-identification-03.txt>
The offer/answer model for SDP assumes that endpoints establish
somehow the QoS required for the media streams they establish.
Endpoints in closed environments typically agree out of band (e.g.,
using configuration information) which QoS mechanism to use.
However, on the Internet, there is more than one QoS service
available. Consequently, there is a need for a mechanism to
negotiate which QoS mechanism to use for a particular media stream.
This document defines such a mechanism.
"Source-Specific Media Attributes in the Session Description Protocol (SDP)",
Jonathan Lennox, Joerg Ott, Thomas Schierl, 31-Oct-08,
<draft-ietf-mmusic-sdp-source-attributes-02.txt>
The Session Description Protocol provides mechanisms to describe
attributes of multimedia sessions and of individual media streams
(e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by
their Synchronization Source Identifiers (SSRCs), in SDP, associate
attributes with these sources, and express relationships among
sources. It also defines several source-level attributes which can
be used to describe properties of media sources.
"Signaling media decoding dependency in Session Description Protocol (SDP)",
Thomas Schierl, Stephan Wenger, 20-Nov-08,
<draft-ietf-mmusic-decoding-dependency-05.txt>
This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP). This is required, for example,
if media data is separated and transported in different network streamsas
a result of the use of a layered or multiple descriptive media coding process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and media format
description(s).
"SDP: Session Description Protocol", Mark Handley, 9-Jun-08,
<draft-ietf-mmusic-rfc4566bis-01.txt>
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.
"Analysis of Middlebox Interactions for Signaling Protocol Communication
along the Media Path", Brian Stucker, Hannes Tschofenig, 14-Jul-08,
<draft-ietf-mmusic-media-path-middleboxes-01.txt>
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.
"The SDP (Session Description Protocol) Grouping Framework", Gonzalo
Camarillo, 6-Jul-08, <draft-ietf-mmusic-rfc3388bis-01.txt>
In this specification, we define a framework to group "m" lines in
SDP (Session Description Protocol) for different purposes. This
framework uses the "group" and "mid" SDP attributes, both of which
are defined in this specification. Additionally, we specify how to
use the framework for two different purposes: for lip synchronization
and for receiving a media flow consisting of several media streams on
different transport addresses.
Multiprotocol Label Switching (mpls)
------------------------------------
"Multiprotocol Label Switching (MPLS) Traffic Engineering Management
Information Base for Fast Reroute", Riza Cetin, Thomas Nadeau, Kiran Koushik,
29-Sep-08, <draft-ietf-mpls-fastreroute-mib-10.txt>
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.
"MPLS Traffic Engineering Soft Preemption", Denver Maddux, Curtis Villamizar,
Amir Birjandi, and Swallow, JP Vasseur, 17-Nov-08,
<draft-ietf-mpls-soft-preemption-14.txt>
This document specifies Multiprotocol Label Switching (MPLS) Traffic
Engineering Soft Preemption, a suite of protocol modifications
extending the concept of preemption with the goal of reducing/
eliminating traffic disruption of preempted Traffic Engineering Label
Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined
supporting only immediate TE LSP displacement upon preemption. The
utilization of a reroute request notification helps more gracefully
mitigate the re-route process of preempted TE LSP. For the brief
period soft preemption is activated, reservations (though not
necessarily traffic levels) are in effect under-provisioned until the
TE LSP(s) can be re-routed. For this reason, the feature is
primarily but not exclusively interesting in MPLS enabled IP networks
with Differentiated Services and Traffic Engineering capabilities.
"Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label
Switching (MPLS) - Extensions to LSP Ping", Seisho Yasukawa, Adrian Farrel,
Zafar Ali, Bill Fenner, George Swallow, Thomas Nadeau, 10-Sep-08,
<draft-ietf-mpls-p2mp-lsp-ping-07.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.
"Component Link Recording and Resource Control for TE Link Bundles",
Intellectual Property, 6-Jul-08,
<draft-ietf-mpls-explicit-resource-control-bundle-04.txt>
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
A.Zamfir et al. - Expires Janury 2009
[page 1]
Component Link Record. & Resource Control for TE Link Bundles Jul.2008
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.
"Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 30-Jun-08,
<draft-ietf-mpls-ldp-p2mp-05.txt>
This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
Label Switching (MPLS) networks. LDP 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.
"MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le
Roux, 8-Jul-08, <draft-ietf-mpls-rsvp-upstream-03.txt>
This document describes procedures for distributing upstream-assigned
labels for Resource Reservation Protocol - Traffic Engineering (RSVP-
TE). It also describes how these procedures can be used for avoiding
branch LSR traffic replication on a LAN for RSVP-TE point-to-
multipoint (P2MP)LSPs.
"MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux,
8-Jul-08, <draft-ietf-mpls-ldp-upstream-03.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 LSR traffic
replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.
"Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB) module", Adrian Farrel, Seisho
Yasukawa, Thomas Nadeau, 30-Apr-08, <draft-ietf-mpls-p2mp-te-mib-07.txt>
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 for point-to-multipoint
(P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering
(TE).
The MIB module defined in this document is applicable to P2MP MPLS-TE
by extensions to the MPLS-TE MIB module defined in RFC 3812. It is
equally applicable to P2MP Generalized MPLS (GMPLS) in association
with the GMPLS TE MIB module defined in RFC 4802.
"Proxy LSP Ping", George Swallow, Vanson Lim, 3-Nov-08,
<draft-ietf-mpls-remote-lsp-ping-03.txt>
This document defines a means of remotely initiating Multiprocal
Label Switched Protocol Pings on Label Switched Paths. A proxy
ping request is sent to any Label Switching Routers along a Label
Switched Path. The primary motivations for this facility are
first to limit the number of messages and related processing when
using LSP Ping in large Point-to-Multipoint LSPs, and second to
enable leaf to root tracing.Contents
"LDP Capabilities", Bob Thomas, 26-Mar-08,
<draft-ietf-mpls-ldp-capabilities-02.txt>
A number of enhancements to the Label Distribution Protocol (LDP)
have been proposed. Some have been implemented, and some are
advancing toward standardization. It is likely that additional
enhancements will be proposed in the future. At present LDP has no
guidelines for advertising such enhancements at LDP session
initialization time. There is also no mechanism to enable and
disable enhancements after the session is established. This document
provides guidelines for advertising LDP enhancements at session
initialization time. It also defines a mechanism to enable and
disable enhancements after LDP session establishment.
"Node behavior upon originating and receiving Resource ReserVation Protocol
(RSVP) Path Error message", JP Vasseur, George Swallow, Ina Minei, 18-Aug-08,
<draft-ietf-mpls-3209-patherr-03.txt>
The aim of this document is to describe a common practice with regard
to the behavior of a node sending a Resource ReserVation Protocol
(RSVP) Traffic Engineering (TE) Path Error message and to the
behavior of a node receiving an RSVP Path Error message for a
preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering
Label Switched Path (TE LSP). This document does not define any new
protocol extensions.
"Security Framework for MPLS and GMPLS Networks", Luyuan Fang, Michael
Behringer, 2-Nov-08,
<draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt>
This document provides a security framework for Multiprotocol Label
Switching (MPLS) and Generalized Multiprotocol Label Switching
(GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and
[RFC3945]). This document addresses the security aspects that are
relevant in the context of MPLS and GMPLS. It describes the
security threats, the related defensive techniques, and the
mechanisms for detection and reporting. This document emphasizes
RSVP-TE and LDP security considerations, as well as Inter-AS and
Inter-provider security considerations for building and maintaining
MPLS and GMPLS networks across different domains or different
Service Providers.
Fang, et al.
Informational
[page 1]
MPLS/GMPLS Security framework
November 2008
"Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", Zafar Ali,
George Swallow, 19-Jun-08,
<draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt>
Expires December 2008
[page 1]
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt
There are many deployment scenarios which require Egress LSR to
receive binding of the RSVP-TE LSP to an application, and payload
identification, using some "out-of-band" (OOB) mechanism. This
document proposes protocol mechanisms to address this
requirement. The procedures described in this document are
equally applicable for point-to-point (P2P) and point-to-
multipoint (P2MP) LSPs.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"An Analysis of Scaling Issues in MPLS-TE Core Networks", Seisho Yasukawa,
Adrian Farrel, Olufemi Komolafe, 19-Jun-08,
<draft-ietf-mpls-te-scaling-analysis-03.txt>
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is
deployed in providers' core networks. As providers plan to grow these
networks, they need to understand whether existing protocols and
implementations can support the network sizes that they are planning.
This document presents an analysis of some of the scaling concerns
for MPLS-TE core networks, and examines the value of two techniques
(LSP hierarchies, and multipoint-to-point LSPs) for improving
scaling. The intention is to motivate the development of appropriate
deployment techniques and protocol extensions to enable the
application of MPLS-TE in large networks.
This document considers only scalability for point-to-point MPLS-TE.
Point-to-multipoint MPLS-TE is for future study.
"LDP IGP Synchronization", Luyuan Fang, 3-Nov-08,
<draft-ietf-mpls-ldp-igp-sync-03.txt>
In certain networks there is a dependency on edge-to-edge LSPs setup
by LDP, e.g. networks that are used for MPLS VPN applications. For
such applications it is not possible to rely on IP forwarding if the
MPLS LSP is not operating appropriately. Blackholing of labeled
traffic can occur in situations where the IGP is operational on a
link but LDP is not operational on that link. While the link could
still be used for IP forwarding, it is not useful for MPLS
M. Jork, A. Atlas, and L. Fang
[page 1]
LDP IGP Synchronization
November 2008
forwarding, for example, MPLS VPN; BGP route free core; or IP
address carried in the packet is out of the RFC1918 space. This
document describes a mechanism to avoid traffic loss due to this
condition without introducing any protocol changes.
""EXP field" renamed to "Traffic Class field"", Loa Andersson, Rajiv Asati,
17-Nov-08, <draft-ietf-mpls-cosfield-def-07.txt>
The early MPLS documents defined the form of the MPLS Label Stack
entry. This include a three bit field called the "EXP field". The
exact use of this field was not defined by these documents, except to
state that it was to be "reserved for experimental use".
Although the intended use of the EXP field was as a "Class of
Service" field, it was not named the "Class of Service" (CoS) field
by these early documents because the use of such a CoS field was not
considered to be sufficiently defined. Today a number of standards
documents define its usage as a CoS field. .
To avoid misunderstanding about how this field may be used, it has
become increasingly necessary to rename this field. This document
changes the name of the field to the "Traffic Class field" ("TC
field".) In doing so it also updates documents that define the
current use of the EXP this field.
"Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, Kireeti
Kompella, George Swallow, 21-Sep-08,
<draft-ietf-mpls-lsp-ping-enhanced-dsmap-01.txt>
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.
"LDP End-of-LIB", Rajiv Asati, Pradosh Mohapatra, Bob Thomas, Emily Chen,
15-Sep-08, <draft-ietf-mpls-ldp-end-of-lib-01.txt>
There are situations following Label Distribution Protocol (LDP)
session establishment where it would be useful for an LDP speaker to
know when its peer has advertised all of its labels. The LDP
specification provides no mechanism for an LDP speaker to notify a
peer when it has completed its initial label advertisements to that
peer. This document specifies means for an LDP speaker to signal
completion of its initial label advertisements following session
establishment.
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri
Papadimitriou, JP Vasseur, 19-Sep-08,
<draft-ietf-mpls-gmpls-lsp-reroute-02.txt>
This document describes how Resource ReserVation Protocol (RSVP)
PathErr Messages may be used to trigger rerouting of Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering (TE) Label Switched Paths (LSPs) without first removing
LSP state or resources. Such LSP rerouting may be desirable in a
number of cases including, for example, soft-preemption and graceful
shutdown. This document describes the usage of existing Standards
Track mechanisms to support LSP rerouting. In this case, it relies on
mechanisms already defined as part of RSVP-TE and simply describes a
sequence of actions to be executed. While existing protocol
definition can be used to support reroute applications, this document
also defines a new reroute-specific error code to allow for the
future definition of reroute application-specific error values.
"MPLS-TP Requirements", Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts,
Nurit Sprecher, 20-Nov-08, <draft-ietf-mpls-tp-requirements-00.txt>
This document specifies the requirements for a MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International
Telecommunications Union (ITU)-IETF effort to include a MPLS
Transport Profile within the IETF MPLS architecture to support the
capabilities and functionalities of a packet transport network as
defined by International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements, MPLS architecture
as defined by IETF and packet transport networks as defined by ITU-T.
Multicast Security (msec)
-------------------------
"Multicast Extensions to the Security Architecture for the Internet
Protocol", Brian Weis, George Gross, Dragan Ignjatic, 6-Jun-08,
<draft-ietf-msec-ipsec-extensions-09.txt>
The Security Architecture for the Internet Protocol describes
security services for traffic at the IP layer. That architecture
primarily defines services for Internet Protocol (IP) unicast
packets. This document describes how the IPsec security services
are applied to IP multicast packets. These extensions are relevant
only for an IPsec implementation that supports multicast.
"Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien
Francillon, Sebastien Faurite, 22-Oct-08,
<draft-ietf-msec-tesla-for-alc-norm-06.txt>
This document details the TESLA packet source authentication and
packet integrity verification protocol and its integration within the
ALC and NORM content delivery protocols. This document only
considers the authentication/integrity verification of the packets
generated by the session's sender. The authentication and integrity
verification of the packets sent by receivers, if any, is out of the
scope of this document.
"Using Counter Modes with Encapsulating Security Payload (ESP) and
Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian
Weis, 9-Jun-08, <draft-ietf-msec-ipsec-group-counter-modes-02.txt>
Advanced Encryption Standard (AES) counter modes use a counter, which
is typically assumed to be incremented by a single sender. This memo
describes the use of AES counter modes when applied to the
Encapsulating Security Payload (ESP) and Authentication Header (AH)
in multiple-sender group applications.
Network Endpoint Assessment (nea)
---------------------------------
"PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita,
Stephen Hanna, Kaushik Narayan, 3-Nov-08, <draft-ietf-nea-pb-tnc-02.txt>
This document specifies PB-TNC, a Posture Broker Protocol identical
to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document
then evaluates PB-TNC against the requirements defined in the NEA
Requirements specification.
"PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC", Kaushik
Narayan, Paul Sangster, 9-Oct-08, <draft-ietf-nea-pa-tnc-02.txt>
This document specifies PA-TNC, a Posture Attribute Protocol
identical to the Trusted Computing Group's IF-M 1.0 protocol.
The document then evaluates PA-TNC against the requirements
defined in the NEA Requirements specification.
Network Configuration (netconf)
-------------------------------
"NETCONF over Transport Layer Security (TLS)", Mohamad Badra, Ibrahim Hajjeh,
22-Oct-08, <draft-ietf-netconf-tls-06.txt>
The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network devices.
This document describes how to use the Transport Layer Security (TLS)
protocol to secure NETCONF exchanges.
"Partial Lock RPC for NETCONF", Balazs Lengyel, Martin Bjorklund, 31-Oct-08,
<draft-ietf-netconf-partial-lock-04.txt>
The NETCONF protocol defines the lock and unlock RPCs, used to lock
entire configuration datastores. In some situations, a way to lock
only parts of a configuration datastore is required. This document
defines a capability-based extension to the NETCONF protocol for
locking portions of a configuration datastore.
"NETCONF Monitoring Schema", Mark Scott, Sharon Chisholm, Martin Bjorklund,
3-Nov-08, <draft-ietf-netconf-monitoring-03.txt>
This document defines NETCONF content via XML Schema to be used to
monitor the NETCONF protocol. The monitoring data model includes
information about NETCONF sessions, locks, and subscriptions and is
intended to facilitate management of a NETCONF server. In addition
this monitoring data provides clients with standardized content to
describe supported schema.
Today, NETCONF capabilities exchange is the only standardized method
a client can use to discover the functionality supported by a NETCONF
server. This works well for static protocol capabilities but is not
well suited for capabilities which could change during a session.
Considerations such as different schema formats, feature optionality
and access controls can all impact the applicability and level of
detail the NETCONF server sends to a client during session setup.
Through updated monitoring data NETCONF clients can adjust their
capabilities throughout a session. Specifically the details returned
can be used by a client to determine whether retrieval of new schema
information is required and includes the information required to
facilitate the retrieval.
A new RPC (get-schema) is also defined to support explicit schema
retrieval via NETCONF.
Network-based Localized Mobility Management (netlmm)
----------------------------------------------------
"IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli,
23-Sep-08, <draft-ietf-netlmm-pmip6-ipv4-support-05.txt>
This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) extending IPv4 home address mobility support to the
mobile node. 2) allowing the mobility entities in the Proxy Mobile
IPv6 domain to exchange signaling messages over an IPv4 transport
network.
"GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri
Gundavelli, Kent Leung, 21-Nov-08, <draft-ietf-netlmm-grekey-option-02.txt>
This document defines a new Mobility Option for allowing the mobile
access gateway and the local mobility anchor to negotiate GRE
encapsulation mode and exchange the downlink and uplink GRE keys
which are used for marking the downlink and uplink traffic that
belong to a specific mobile node session or a specific flow.
"Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev
Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 30-Sep-08,
<draft-ietf-netlmm-pmipv6-heartbeat-01.txt>
Proxy Mobile IPv6 is a network-based mobility management protocol.
The mobility entities involved in the Proxy Mobile IPv6 protocol, the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA),
setup tunnels dynamically to manage mobility for a mobile node within
the Proxy Mobile IPv6 domain. This document describes a heartbeat
mechanism between the MAG and the LMA to detect failures quickly and
take appropriate action.
"Interactions between PMIPv6 and MIPv6: scenarios and related issues",
Gerardo Giaretta, 17-Nov-08, <draft-ietf-netlmm-mip-interactions-01.txt>
The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
(MIPv6) protocols are both deployed in a network require some
analysis and considerations. This document describes all identified
possible scenarios, which require an interaction between PMIPv6 and
MIPv6 and discusses all issues related to these scenarios. Solutions
and reccomendations to enable these scenarios are also described.
NETCONF Data Modeling Language (netmod)
---------------------------------------
"YANG - A data modeling language for NETCONF", Martin Bjorklund, 3-Nov-08,
<draft-ietf-netmod-yang-02.txt>
YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications.
"Common YANG Data Types", Juergen Schoenwaelder, 3-Nov-08,
<draft-ietf-netmod-yang-types-01.txt>
This document introduces a collection of common data types to be used
with the YANG data modeling language.
Network File System Version 4 (nfsv4)
-------------------------------------
"RPC: Remote Procedure Call Protocol Specification Version 2", Robert
Thurlow, 30-Oct-08, <draft-ietf-nfsv4-rfc1831bis-10.txt>
This document describes the ONC (Open Network Computing) Remote
Procedure Call (ONC RPC Version 2) protocol as it is currently
deployed and accepted. This document obsoletes [RFC1831].
"NFS RDMA Problem Statement", Thomas Talpey, Chet Juszczak, Intellectual
Property, 21-Feb-08, <draft-ietf-nfsv4-nfs-rdma-problem-statement-08.txt>
This draft addresses enabling the use of Remote Direct Memory
Access (RDMA) by the Network File System (NFS) protocols. NFS
implementations historically incur significant overhead due to data
copies on end-host systems, as well as other processing overhead.
The potential benefits of RDMA to these implementations are
explored, and the reasons why RDMA is especially well-suited to NFS
and network file protocols in general are evaluated.
"Remote Direct Memory Access Transport for Remote Procedure Call", Thomas
Talpey, Brent Callaghan, Intellectual Property, 16-Apr-08,
<draft-ietf-nfsv4-rpcrdma-08.txt>
A protocol is described providing Remote Direct Memory Access
(RDMA) as a new transport for Remote Procedure Call (RPC). The
RDMA transport binding conveys the benefits of efficient, bulk data
transport over high speed networks, while providing for minimal
change to RPC applications and with no required revision of the
application RPC protocol, or the RPC protocol itself.
"NFS Direct Data Placement", Thomas Talpey, Brent Callaghan, Intellectual
Property, 16-Apr-08, <draft-ietf-nfsv4-nfsdirect-08.txt>
This draft defines the bindings of the various Network File System
(NFS) versions to the Remote Direct Memory Access (RDMA) operations
supported by the RPC/RDMA transport protocol. It describes the use
of direct data placement by means of server-initiated RDMA operations
into client-supplied buffers for implementations of NFS versions 2,
3, 4 and 4.1 over such an RDMA transport.
"NFS Version 4 Minor Version 1", Spencer Shepler, Mike Eisler, David Noveck,
5-Sep-08, <draft-ietf-nfsv4-minorversion1-26.txt>
This Internet-Draft describes NFS version 4 minor version one,
including features retained from the base protocol and protocol
extensions made subsequently. Major extensions introduced in NFS
version 4 minor version one include: Sessions, Directory Delegations,
and parallel NFS (pNFS).
"pNFS Block/Volume Layout", David Black, Stephen Fridella, Jason Glasgow,
11-Jun-08, <draft-ietf-nfsv4-pnfs-block-09.txt>
Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access
file data on the storage used by the NFSv4 server. This ability to
bypass the server for data access can increase both performance and
parallelism, but requires additional client functionality for data
access, some of which is dependent on the class of storage used. The
main pNFS operations draft specifies storage-class-independent
extensions to NFS; this draft specifies the additional extensions
(primarily data structures) for use of pNFS with block and volume
based storage.
"Object-based pNFS Operations", Benny Halevy, Brent Welch, Jim Zelenka,
19-Jun-08, <draft-ietf-nfsv4-pnfs-obj-09.txt>
This Internet-Draft provides a description of the object-based pNFS
extension for NFSv4. This is a companion to the main pnfs
specification in the NFSv4 Minor Version 1 Internet Draft, which is
currently draft-ietf-nfsv4-minorversion1-23.
"NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David
Noveck, 5-Sep-08, <draft-ietf-nfsv4-minorversion1-dot-x-09.txt>
This Internet-Draft provides the XDR description for NFSv4 minor
version one.
"RPCSEC_GSS Version 2", Mike Eisler, 9-Oct-08,
<draft-ietf-nfsv4-rpcsec-gss-v2-06.txt>
This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
Version 2 is the same as Version 1 but adds support for channel
bindings.
"IANA Considerations for RPC Net Identifiers and Universal Address Formats",
Mike Eisler, 19-Aug-08, <draft-ietf-nfsv4-rpc-netid-03.txt>
This Internet-Draft lists IANA Considerations for RPC Network
Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
This Internet-Draft updates, but does not replace, RFC1833.
"Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig
Everhart, Andy Adamson, Jiaying Zhang, 26-Sep-08,
<draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt>
The NFS version 4 protocol provides a natural way for a collection of
NFS file servers to collaborate in providing an organization-wide
file name space. The DNS SRV RR allows a simple and appropriate way
for an organization to publish the root of its name space, even to
clients that might not be intimately associated with such an
organization. DNS SRV can be used to join these organization-wide
file name spaces together to allow construction of a global, uniform
NFS version 4 file name space. This document refreshes the draft.
"Administration Protocol for Federated Filesystems", Daniel Ellard, Craig
Everhart, James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08,
<draft-ietf-nfsv4-federated-fs-admin-00.txt>
This document describes the administration protocol for a federated
file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers and collections of
fileservers with different administrators can form a fileserver
federation that provides a namespace composed of the filesystems
physically hosted on and exported by the constituent fileservers.
"Requirements for Federated File Systems", Daniel Ellard, Craig Everhart,
James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08,
<draft-ietf-nfsv4-federated-fs-reqts-00.txt>
This draft describes and lists the functional requirements of a
federated file system and defines related terms. Our intent is to
use this draft as a starting point and refine it, with input and
feedback from the file system community and other interested parties,
until we reach general agreement. We will then begin, again with the
help of any interested parties, to define standard, open federated
file system protocols that satisfy these requirements and are
suitable for implementation and deployment.
"NSDB Protocol for Federated Filesystems", Daniel Ellard, Craig Everhart,
James Lentini, Renu Tewari, Manoj Naik, 26-Sep-08,
<draft-ietf-nfsv4-federated-fs-protocol-00.txt>
This document describes a file system 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 and collections of fileservers
with different administrators can form a fileserver federation that
provides a namespace composed of the filesystems physically hosted on
and exported by the constituent fileservers.
Individual Submissions (none)
-----------------------------
"Salted Challenge Response (SCRAM) SASL Mechanism", Abhijit Menon-Sen, Alexey
Melnikov, Chris Newman, 19-Nov-08, <draft-newman-auth-scram-07.txt>
The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security
(TLS). There are some significant security concerns with that
mechanism, which could be addressed by the use of a challenge
response authentication mechanism protected by TLS. Unfortunately,
the challenge response mechanisms presently on the standards track
all fail to meet requirements necessary for widespread deployment,
and have had success only in limited use.
This specification describes a family of authentication mechanisms
called the Salted Challenge Response Authentication Mechanism
(SCRAM), which addresses the security concerns and meets the
deployability requirements. When used in combination with TLS or an
equivalent security layer, a mechanism from this family could
improve the status-quo for application protocol authentication and
provide a suitable choice for a mandatory-to-implement mechanism for
future application protocol standards.
"Cisco Systems' Simple Certificate Enrollment Protocol", Xiaoyi Liu,
26-Jun-08, <draft-nourse-scep-17.txt>
This document specifies the Simple Certificate Enrollment Protocol, a
PKI communication protocol which leverages existing technology by
using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment
protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now
enjoys wide support in both client and CA implementations.
"LDAP Administrators Address Attribute", Mark Wahl, 6-Sep-07,
<draft-wahl-ldap-adminaddr-05.txt>
Organizations with multiple or outsourced directory servers need the
ability for administrators to determine who is responsible for a
particular directory server. This document defines an attribute with
contact information for a directory server's responsible party,
conceptually similar to the 'sysContact' object of SNMP, which can be
retrieved from the directory server using the Lightweight Directory
Access Protocol.
"Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka
Riikonen, 23-Jan-07, <draft-riikonen-silc-spec-09.txt>
This memo describes a Secure Internet Live Conferencing (SILC)
protocol which provides secure conferencing services over insecure
network channel. SILC provides advanced and feature rich conferencing
services with security as main design principal. Strong cryptographic
methods are used to protect SILC packets inside the SILC network.
Three other specifications relates very closely to this memo;
SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
Protocols [SILC3] and SILC Commands [SILC4].
"SILC Packet Protocol", Pekka Riikonen, 19-Jan-07,
<draft-riikonen-silc-pp-09.txt>
This memo describes a Packet Protocol used in the Secure Internet Live
Conferencing (SILC) protocol, specified in the Secure Internet Live
Conferencing, Protocol Specification [SILC1]. This protocol describes
the packet types and packet payloads which defines the contents of the
packets. The protocol provides secure binary packet protocol that
assures that the contents of the packets are secured and authenticated.
"SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 19-Jan-07,
<draft-riikonen-silc-ke-auth-09.txt>
This memo describes two protocols used in the Secure Internet Live
Conferencing (SILC) protocol, specified in the Secure Internet Live
Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
(SKE) protocol provides secure key exchange between two parties
resulting into shared secret key material. The protocol is based
on Diffie-Hellman key exchange algorithm and its functionality is
derived from several key exchange protocols.
The second protocol, SILC Connection Authentication protocol provides
user level authentication used when creating connections in SILC
network. The protocol supports passphrase (pre-shared secret)
authentication and public key (and certificate) authentication based
on digital signatures.
"LDAP Transactions", Kurt Zeilenga, 14-Jul-08,
<draft-zeilenga-ldap-txn-12.txt>
Lightweight Directory Access Protocol (LDAP) update operations, such
as Add, Delete, and Modify operations, have atomic, consistency,
isolation, durability (ACID) properties. Each of these update
operations act upon an entry. It is often desirable to update two or
more entries in a single unit of interaction, a transaction.
Transactions are necessary to support a number of applications
including resource provisioning. This document extends LDAP to
support transactions.
"Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands,
3-Jul-08, <draft-rosen-vpn-mcast-09.txt>
This draft describes the deployed MVPN (Multicast in BGP/MPLS IP
VPNs) solution of Cisco Systems.
"The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers,
22-May-08, <draft-kunze-ark-15.txt>
The ARK (Archival Resource Key) naming scheme is designed to
facilitate the high-quality and persistent identification of
information objects. A founding principle of the ARK is that
persistence is purely a matter of service and is neither inherent in
an object nor conferred on it by a particular naming syntax. The
best that an identifier can do is to lead users to the services that
support robust reference. The term ARK itself refers both to the
scheme and to any single identifier that conforms to it. An ARK has
five components:
[http://NMAH/]ark:/NAAN/Name[Qualifier]
an optional and mutable Name Mapping Authority Hostport (usually a
hostname), the "ark:" label, the Name Assigning Authority Number
(NAAN), the assigned Name, and an optional and possibly mutable
Qualifier supported by the NMA. The NAAN and Name together form the
immutable persistent identifier for the object independent of the URL
hostname. An ARK is a special kind of URL that connects users to
three things: the named object, its metadata, and the provider's
promise about its persistence. When entered into the location field
of a Web browser, the ARK leads the user to the named object. That
same ARK, inflected by appending a single question mark (`?'),
returns a brief metadata record that is both human- and machine-
readable. When the ARK is inflected by appending dual question marks
(`??'), the returned metadata contains a commitment statement from
the current provider. Tools exist for minting, binding, and
resolving ARKs.
"SILC Commands", Pekka Riikonen, 19-Jan-07,
<draft-riikonen-silc-commands-07.txt>
This memo describes the commands used in the Secure Internet Live
Conferencing (SILC) protocol, specified in the Secure Internet Live
Conferencing, Protocol Specification [SILC1]. The SILC Commands are
very important part of the SILC protocol. Usually the commands are used
by SILC clients to manage the SILC session, but also SILC servers may
use the commands. This memo specifies detailed command messages and
command reply messages.
"Multicast DNS", Stuart Cheshire, Marc Krochmal, 11-Sep-08,
<draft-cheshire-dnsext-multicastdns-07.txt>
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, is becoming essential.
Multicast DNS (mDNS) provides the ability to do 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.
"Requirements for Replacing AppleTalk", Stuart Cheshire, Marc Krochmal,
17-Nov-08, <draft-cheshire-dnsext-nbp-07.txt>
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.
"Compressed Data within an Internet EDI Message", Terry Harding, 27-Aug-08,
<draft-ietf-ediint-compression-12.txt>
This document explains the rules and procedures for utilizing
compression (RFC 3274) within an Internet EDI (Electronic
Data Interchange) 'AS' message, as defined in RFCs 3335, 4130,
and 4823.
"URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila,
4-Sep-08, <draft-wilde-sms-uri-16.txt>
This memo specifies the Uniform Resource Identifier (URI) scheme
"sms" for specifying one or more recipients for an SMS message. SMS
messages are two-way paging messages that can be sent from and
received by a mobile phone or a suitably equipped networked device.
"Analysis of Inter-Domain Routing Requirements and History", Elwyn Davies,
Avri Doria, 8-Aug-08, <draft-irtf-routing-history-09.txt>
This document analyses the state of the Internet domain-based routing
system, concentrating on Inter-Domain Routing (IDR) and also
considering the relationship between inter-domain and intra-domain
routing. The analysis is carried out with respect to RFC 1126 and
other IDR requirements and design efforts looking at the routing
system as it appeared to be in 2001 with editorial additions
reflecting developments up to 2006. It is the companion document to
"A Set of Possible Requirements for a Future Routing Architecture"
[I-D.irtf-routing-reqs], which is a discussion of requirements for
the future routing architecture, addressing systems developments and
future routing protocols. This document summarizes discussions held
several years ago by members of the IRTF Routing Research Group (IRTF
RRG) and other interested parties. The document is published with
the support of the IRTF RRG as a record of the work completed at that
time, but with the understanding that it does not necessarily
represent either the latest technical understanding or the technical
concensus of the research group at the date of publication.
[Note to RFC Editor: Please replace the reference in the abstract
with a non-reference quoting the RFC number of the companion
document when it is allocated, i.e., '(RFC xxxx)' and remove this
note.]
"IMAP METADATA Extension", Cyrus Daboo, 18-Nov-08,
<draft-daboo-imap-annotatemore-16.txt>
The METADATA extension to the Internet Message Access Protocol
permits clients and servers to maintain "annotations" or "meta data"
on IMAP servers. It is possible to have annotations on a per-mailbox
basis or on the server as a whole. For example, this would allow
comments about the purpose of a particular mailbox to be "attached"
to that mailbox, or a "message of the day" containing server status
information to be made available to anyone logging in to the server.
"An IPv4 Flowlabel Option", Thomas Dreibholz, 11-Jul-08,
<draft-dreibholz-ipv4-flowlabel-08.txt>
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.
"SILC Message Flag Payloads", Pekka Riikonen, 26-May-05,
<draft-riikonen-flags-payloads-04.txt>
This memo describes the data payloads associated with the SILC Message
Flags, as defined in the SILC Packet Protocol specification [SILC2]. The
purpose of the Message Flags is to augment the function of the Message Payload
used to send both private and channel messages, by allowing the sender to
tell the receiver what type of data the payload includes, and how the data
should be processed. Some of the Message Flags may define additional payloads
to be associated with the flag, and this memo describes these payloads.
"User Online Presence and Information Attributes", Pekka Riikonen, 19-Jan-07,
<draft-riikonen-presence-attrs-04.txt>
This document defines set of attributes that can represent the online
user's presence in a network, and to provide general information about
the user. The purpose is to provide a generic mechanism to share
online presence and status, and general information about the user
to be used in several kind of network protocols and applications.
These attributes could be used by for example chat and conferencing
protocols (such as Instant Message protocols), network games, and
other similar network protocols and applications that has online
users in a network.
"Advertisement of Multiple Paths in BGP", Daniel Walton, 14-Jul-08,
<draft-walton-bgp-add-paths-06.txt>
In this document we propose a BGP extension that allows the
advertisement of multiple paths for the same address prefix without
the new paths implicitly replacing any previous ones. The essence of
the extension is that each path is identified by a path identifier in
addition to the address prefix.
"Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno,
26-May-05, <draft-gpaterno-wireless-pppoe-13.txt>
This document explores the use of Point-To-Point Protocol over
Ethernet (PPPoE) to provide wireless access to the Internet and
suggests how the infrastructure can be deployed. The document targets
consumers, corporations, Internet Service Providers, and mobile phone
operators that provide user access through Wireless LANs technologies
such as IEEE 802.11.
"EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 4-Aug-08,
<draft-urien-eap-smartcard-15.txt>
This document describes the functional interface, based on the
ISO7816 standard, to EAP methods, fully and securely executed in
smart cards. This class of tamper resistant device may deliver
client or server services; it can compute Root Keys from an Extended
Master Session Key (EMSK).
"Guidelines for Specifying the Use of IPsec Version 2", Steven Bellovin,
3-Aug-08, <draft-bellovin-useipsec-10.txt>
The Security Considerations sections of many Internet Drafts say, in
effect, "just use IPsec". While this is sometimes correct, more
often it will leave users without real, interoperable security
mechanisms. This memo offers some guidance on when IPsec Version 2
should and should not be specified.
"Split Multi-link Trunking (SMLT)", Roger Lapuh, Dinesh Mohan, Richard
Mcgovern, 8-Jul-08, <draft-lapuh-network-smlt-08.txt>
This document describes Split Multi-link Trunking (SMLT) for bridged
and routed networks. SMLT enables topologies with upstream node
redundancy for increased reliability of Layer 2 link aggregationsubnetworks
based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC3768].
SMLT is an improvement over Multi-Link Trunking (MLT), a method of
link aggregation that allows multiple Ethernet links to be aggregated
together, and handled as a single logical trunk. MLT can be realized
via many different link aggregation mechanisms. Several methods of
MLT are in use today; one example is [IEEE 802.3ad].
SMLT is MLT with links of a link-aggregation group connected to ports
on two different devices (e.g. SMLT client and aggregation device).
Unlike MLT, at least one end of a link-aggregated group is dual-homed
to two different SMLT aggregation devices. In many cases those
devices act as bridges (switches) as well as L3 routers (Routing
Switches). These two redundant SMLT aggregation devices can share one
or more VRRP routing instances; for that SMLT-VRRP extends the VRRP
functionality to an active-active router concept, where both SMLT
aggregation device route traffic for a common VRRP-ID, thus load
balancing traffic not only for L2 but also for L3.
"DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal, 11-Sep-08,
<draft-cheshire-dnsext-dns-sd-05.txt>
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.
"Reliable Server Pooling Applicability for IP Flow Information Exchange",
Thomas Dreibholz, Lode Coene, Phillip Conrad, 11-Jul-08,
<draft-coene-rserpool-applic-ipfix-06.txt>
This document describes the applicability of the Reliable Server
Pooling architecture to the IP Flow Information Exchange using the
Aggregate Server Access Protocol (ASAP) functionality of RSerPool
only. Data exchange in IPFIX between the router and the data
collector can be provided by a limited retransmission protocol.
"Early Retransmit for TCP and SCTP", Mark Allman, 25-Jun-08,
<draft-allman-tcp-early-rexmt-07.txt>
This document proposes a new mechanism for TCP and SCTP that can be
used to recover lost segments when a connection's congestion window
is small. The "Early Retransmit" mechanism allows the transport to
reduce, in certain special circumstances, the number of duplicate
acknowledgments required to trigger a fast retransmission. This
allows the transport to use fast retransmit to recover packet losses
that would otherwise require a lengthy retransmission timeout.
"The LDAP No-Op Control", Kurt Zeilenga, 14-Jul-08,
<draft-zeilenga-ldap-noop-12.txt>
This document defines the Lightweight Directory Access Protocol (LDAP)
No-Op control which can be used to disable the normal effect of an
operation. The control can be used to discover how a server might
react to a particular update request without updating the directory.
"Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)",
Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas
Pashalidis, 3-Nov-08, <draft-lior-radius-prepaid-extensions-15.txt>
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.
"Lumas - Language for Universal Message Abstraction and Specification", Peter
Cordell, 2-Feb-07, <draft-cordell-lumas-05.txt>
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.
"A Set of Possible Requirements for a Future Routing Architecture", Avri
Doria, Elwyn Davies, Frank Kastenholz, 15-Jun-08,
<draft-irtf-routing-reqs-10.txt>
The requirements for routing architectures described in this document
were produced by two sub-groups under the IRTF Routing Research Group
in 2001, with some editorial updates up to 2006. The two sub-groups
worked independently, and the resulting requirements represent two
separate views of the problem and of what is required to fix the
problem. This document may usefully serve as part of the recommended
reading for anyone who works on routing architecture designs for the
Internet in the future.
The document is published with the support of the IRTF RRG as a
record of the work completed at that time, but with the understanding
that it does not necessarily represent either the latest technical
understanding or the technical consensus of the research group at the
date of publication.
"Cisco Systems' Private VLANs: Scalable Security in a Multi-Client
Environment", Sanjib HomChaudhuri, Marco Foschiano, 19-Aug-08,
<draft-sanjib-private-vlan-10.txt>
This document describes a mechanism to achieve device isolation
through the application of special Layer 2 forwarding constraints.
Such mechanism allows end devices to share the same IP subnet while
being Layer 2 isolated, which in turn allows network designers to
employ larger subnets and so reduce the address management overhead.
Some of the numerous deployment scenarios of the aforementioned
mechanism (which range from data center designs to Ethernet-to-the-
home basement networks) are mentioned in the following to exemplify
its possible usages; however, this document is not intended to cover
all such deployment scenarios nor delve into their details.
"A Bound End-to-End Tunnel (BEET) mode for ESP", Pekka Nikander, Jan Melen,
5-Aug-08, <draft-nikander-esp-beet-mode-09.txt>
This document specifies a new mode, called Bound End-to-End Tunnel
(BEET) mode, for IPsec ESP. The new mode augments the existing ESP
tunnel and transport modes. For end-to-end tunnels, the new mode
provides limited tunnel mode semantics without the regular tunnel
mode overhead. The mode is intended to support new uses of ESP,
including mobility and multi-address multi-homing.
"Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall
Stewart, Peter Lei, Michael Tuexen, 22-Oct-08,
<draft-stewart-sctp-pktdrprep-08.txt>
This document describes a new chunk type for SCTP. This new chunk
type can be used by both endhosts and routers to report the loss of
SCTP datagrams due to errors in transmission or other drops not due
to congestion.
"Example call flows using SIP security mechanisms", Cullen Jennings, Kumiko
Ono, 7-Jul-08, <draft-jennings-sip-sec-flows-03.txt>
This document shows call flows demonstrating the use of SIPS, TLS,
and S/MIME in SIP. This draft provides information that helps
implementers build interoperable SIP software. It is purely
informational. To help facilitate interoperability testing, it
includes certificates used in the example call flows and a CA
certificate to create certificates for testing.
This work is being discussed on the sip@ietf.org mailing list.
"Session Initiation Protocol (SIP) Event Notification Extension for
Notification Throttling", Aki Niemi, Krisztian Kiss, Salvatore Loreto,
22-Oct-08, <draft-niemi-sipping-event-throttle-07.txt>
This memo specifies the throttle, forge and average mechanisms for
adjusting the rate of Session Initiation Protocol (SIP) event
notifications. These mechanisms can be applied in subscriptions to
all SIP event packages, but in particular the throttle mechanism is
especially designed to be used in combination with a subscription to
a Resource List Server (RLS).
"SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05,
<draft-massar-v6ops-heartbeat-01.txt>
This document proposes a heartbeat protocol for signalling
availability of hosts with a specific emphasis on providing a
signalling protocol for allowing dynamic non-24/7 endnodes to use
tunnel's of the various IPv6 Tunnel Brokers.
"Mixmaster Protocol Version 2", U Moeller, 30-Dec-04,
<draft-sassaman-mixmaster-03.txt>
Most e-mail security protocols only protect the message body, leaving
useful information such as the identities of the conversing parties,
sizes of messages and frequency of message exchange open to
adversaries. This document describes Mixmaster version 2, a mail
transfer protocol designed to protect electronic mail against traffic
analysis.
"Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network
Access Authentication", Hannes Tschofenig, Alper Yegin, Dan Forsberg,
14-Jul-08, <draft-yegin-eap-boot-rfc3118-03.txt>
The DHCP authentication extension (RFC 3118) cannot be widely
deployed due to lack of a key agreement protocol. This document
outlines how EAP-based network access authentication mechanisms can
be used to establish bootstrap keying material that can be used to
subsequently use RFC 3118 security.
"IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet,
Florent Parent, 6-May-08, <draft-blanchet-v6ops-tunnelbroker-tsp-04.txt>
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the
establishment of tunnels of various inner protocols, such as IPv6 or
IPv4, inside various outer protocols packets, such as IPv4, IPv6 or
UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is
used by the tunnel client to negotiate the tunnel with the broker. A
mobile node implementing TSP can be connected to both IPv4 and IPv6
networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6
only. A tunnel broker may terminate the tunnels on remote tunnel
servers or on itself. This document describes the TSP protocol
within the model of the tunnel broker model.
"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS",
Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 21-Aug-08,
<draft-kappler-nsis-qosmodel-controlledload-08.txt>
This document describes a QoS Model to signal IntServ controlled load
service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS
Model specific information is carried in an opaque object, the QSPEC.
This document hence specifies the QSPEC for controlled load service,
how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP
messages must be used.
"DNS Blacklists and Whitelists", John Levine, 17-Nov-08,
<draft-irtf-asrg-dnsbl-08.txt>
The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared blacklists and whitelists of IP
addresses or domains. The DNS has become the de-facto standard
method of distributing these blacklists and whitelists. This memo
documents the structure and usage of DNS based blacklists and
whitelists, and the protocol used to query them.
IRTF Notice
This document is a product of the Anti-Spam Research Group (ASRG) of
the Internet Research Task Force. It represents the consensus of the
ASRG with respect to practices to improve interoperability of DNS
based blacklists and whitelists, but does not constitute an IETF or
Internet standard.
[NOTE TO RFC EDITOR: Please remove this paragraph in publication.]
Comments and discussion may be directed to the ASRG mailing list,
asrg@irtf.org.
"Guidelines for Management of DNSBLs for Email", Chris Lewis, Matt Sergeant,
17-Nov-08, <draft-irtf-asrg-bcp-blacklists-05.txt>
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 discusses guidelines 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 will seek BCP status. Comments and discussion of this
document should be addressed to the asrg@ietf.org mailing list.
"RADIUS Error Messages", Glen Zorn, 17-Nov-08,
<draft-zorn-radius-err-msg-10.txt>
This document describes new RADIUS protocol elements designed to
allow the communication of packet and attribute errors between RADIUS
servers and clients.
"Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07,
<draft-ohara-capwap-lwapp-04.txt>
In the recent years, there has been a shift in wireless LAN product
architectures from autonomous access points to centralized control of
light weight access points. The general goal has been to move most
of the traditional wireless functionality such as access control
(user authentication and authorization), mobility and radio
management out of the access point into a centralized controller.
The IETF's CAPWAP WG has identified that a standards based protocol
is necessary between a wireless Access Controller and Wireless
Termination Points (the latter are also commonly referred to as Light
Weight Access Points). This specification defines the Light Weight
Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol
requirements. Although the LWAPP protocol is designed to be flexible
enough to be used for a variety of wireless technologies, this
specific document describes the base protocol, and an extension that
allows it to be used with the IEEE's 802.11 wireless LAN protocol.
"Nested Nemo Tree Discovery", Pascal Thubert, Caroline Bontoux, Nicolas
Montavont, Ben McCarthy, 1-Aug-08, <draft-thubert-tree-discovery-07.txt>
This paper describes a simple distance vector protocol that exposes
only a default route towards the infrastructure in a nested NEMO
configuration. The draft extends the Neighbor Discovery Protocol [1]
in order to carry information and metrics which will help a Mobile
Router select its Attachment Router(s) in an autonomous fashion and
provides generic rules which guarantee that the interaction of
different selection processes will not create loops.
"Internet Mail Architecture", Dave Crocker, 31-Oct-08,
<draft-crocker-email-arch-11.txt,.pdf>
Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service. These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness. To collaborate productively on
this large and complex system, all participants must work from a
common view of it and use a common language to describe its
components and the interactions among them. But the many differences
in perspective currently make it difficult to know exactly what
another participant means. To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.
"IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano
Previdi, Mike Shand, 16-Nov-07, <draft-bryant-ipfrr-tunnels-03.txt>
This draft describes an IP fast re-route mechanism that provides
backup connectivity in the event of a link or router failure. In the
absence of single points of failure and asymmetric costs, the
mechanism provides complete protection against any single failure.
If perfect repair is not possible, the identity of all the
unprotected links and routers is known in advance.
This IP Fast Reroute advanced method was invented in 2002 and draft
(draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to
the IETF in May 2004. It was one of the first methods of achieving
full repair coverage in an IP Network, and as such the draft has been
widely referenced in the academic literature.
The authors DO NOT propose that this IPFRR method be implemented
since better IPFRR advanced method capable of achieving full repair
coverage have subsequently been invented.
"DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie,
17-Nov-05, <draft-manning-opcode-discover-02.txt>
This document describes the DISCOVER opcode, an experimental
extension to the Domain Name System (DNS) to use multicast queries
for resource discovery. A client multicasts a DNS query using the
DISCOVER opcode and processes the multiple responses that may
result.
"RADIUS Attributes for the Delivery of Keying Material", Glen Zorn,
17-Apr-07, <draft-zorn-radius-keywrap-13.txt>
This document defines a set of RADIUS Attributes designed to allow
both the secure transmission of cryptographic keying material and
strong authentication of any RADIUS message.
"Extending the Space Available for TCP Options", Wesley Eddy, Adam Langley,
1-Jul-08, <draft-eddy-tcp-loo-04.txt>
This document describes a method for increasing the space available
for TCP options. Two new TCP options (LO and SLO) are detailed which
reduce the limitations imposed by the TCP header's Data Offset field.
The LO option provides this extension after connection establishment,
and the SLO option aids in transmission of lengthy connection
initialization and configuration options.
"TLS Express", Mohamad Badra, 16-Feb-05, <draft-badra-tls-express-01.txt>
This document defines a new extension that may be used to add Pre
Shared Key authentication functionality to TLS. It is based on the
TLS abbreviated handshake and it provides the ability to share a
session key for data encryption.
"IPv6 Label Switching Architecture", Sham Chakravorty, Jeff Bush, Jim Bound,
9-Jul-08, <draft-chakravorty-6lsa-03.txt>
This specification provides an architectural framework, called IPv6
Label Switching Architecture or 6LSA, for an end-to-end, IP-centric
packet transmission technique that uses the IPv6 packet header Flow
Label to establish IPv6-based label switched paths. The label
switched paths, called 6LSPs, provide application and user specified
routes for efficient transport of packets and as means for quality of
service (QoS) delivery, IPv4 tunneling, VPN and other mechanisms.
Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses,
the architecture may provide potential memory and processing savings,
the latter through significantly reduced address fetches for the low-
powered, handheld devices. The label has two components comprising
Global Label value and Local Label value. The Global Label value
from the source is delivered to the destination unmodified. However,
the intermediate network nodes in 6LSA are allowed to temporarily
replace the Local Label value with a value of local significance.
This enables 6LSA flows to be hop-specific although session-based and
as such a unique QoS delivery technique for bandwidth constrained
media. 6LSA also enhances security since label generation and
assignment algorithms can be modified periodically.
Finally, it must be pointed out that the 6LSA concept of temporary
flow label assignment is applicable to the 6LSA domain only. The
concept is not applicable to domains outside the 6LSA.
"SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06,
<draft-mehta-rmt-flute-sdp-05.txt>
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.
"Scope Modifiers in Intellectual Property Declarations", I Maturana, I
Robredo, 16-Aug-05, <draft-maturana-ipscope-02.txt>
The purpose of this RFC is to focus discussion on intellectual
property problems in the Internet.
This document introduces and defines scope modifiers to be used in
intellectual property declarations. These modifiers abstract the
ownership behavior of resources available in interoperable
environnments, such as the Internet.
"The IPvLX Architecture", Fred Templin, 11-May-07,
<draft-templin-ipvlx-08.txt>
The IETF has embraced IPv6 as the next-generation Internet protocol,
but global IPv4 deployment continues in private addressing domains
behind Network Address Translators (NATs). This document envisions a
long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as
identifiers (and sometimes also locators) and IPv4 addresses serving
as locators (and sometimes also identifiers). This document proposes
an architectural framework for IPv6/IPv4 coexistence called: "IPvLX
(IP with virtual Link Extension)".
"Message Header Field for Indicating Message Authentication Status", Murray
Kucherawy, 24-Oct-08, <draft-kucherawy-sender-auth-header-17.txt>
This memo defines a new message header field for use with electronic
mail messages to indicate the results of message authentication
efforts. Mail user agents (MUAs) may use this message header field
to relay that information in a convenient way to users or to make
sorting and filtering decisions.
"HIP Experiment Report", Tom Henderson, Andrei Gurtov, 14-Jul-08,
<draft-irtf-hip-experiment-04.txt>
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 HIP to host
protocol stack, Internet infrastructure, and applications. The
perspective of the network operator, as well as a list of HIP
experiments are presented as well.
"Common Intrusion Detection Signatures Standard", Adam Wierzbicki, Jacek
Kalinski, Tomasz Kruszona, 4-Sep-08, <draft-wierzbicki-cidss-05.txt>
The purpose of the Common Intrusion Detection Signatures Standard
(CIDSS) is to define a common data format for storing signatures from
different intrusion detection systems.
This Internet-Draft describes a common data format to represent
information contained in signatures of intrusion detection systems,
and explains the rationale for using this common format. The proposed
format is a dialect of the Extensible Markup Language (XML). An XML
Document Type Definition is developed, and examples are provided.
"Network-Layer Signaling: Transport Layer", Melinda Shore, David McGrew,
Kaushik Biswas, 13-Jul-08, <draft-shore-nls-tl-06.txt>
The RSVP model for communicating requests to network devices along a
datapath has proven useful for a variety of applications beyond what
the protocol designers envisioned, and while the architectural model
generalizes well the protocol itself has a number of features that
limit its applicability to applications other than IntServ. Network
Layer Signaling uses the RSVP on-path communication model and
provides a lightweight transport layer for non-QoS signaling
applications, such as discovery or diagnostics. It is based on a
"two-layer" architecture that divides protocol function into
transport and application. This document describes the transport
protocol.
"Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs",
Joseph Touch, 8-Jul-08, <draft-touch-msword-template-v2.0-07.txt>
This document describes the properties and use of a revised Microsoft
Word template (.dot) for writing Internet Drafts and RFCs. It updates
the initial template described in RFC 3285 to more fully support
Word's outline modes and to be easier to use. This template can be
direct-printed and direct-viewed, where either is line-for-line
identical with RFC Editor-compliant ASCII output. This version is
intended as an update to RFC3285.
The most recent version of this template and post-processing scripts
are available at http://www.isi.edu/touch/tools
"Bounding Longer Routes to Remove TE", Susan Hares, 31-Jul-08,
<draft-white-bounded-longest-match-02.txt>
Some ASes currently use length-based filters to manage the size of
the routing table they use and propagate. This draft explores an
alternative to length-based filters which allows for more automatic
configuration and which provides for better redundancy.
Rather than use a filter, this draft proposes a method of modifying
the BGP [RFC1771] longest match algorithm by setting a bound on the
prefix lengths eligible for preference. A bound would operate on
long prefixes when covering route announcements are available; in
certain circumstances it would cause a router to prefer an aggregate
over a more specific route announcement.
"The "OpenPGP" mail and news header field", Atom Smasher, Simon Josefsson,
20-May-08, <draft-josefsson-openpgp-mailnews-header-06.txt>
This document describes the "OpenPGP" mail and news header field.
The field provide information about the sender's OpenPGP key.
See <http://josefsson.org/openpgp-header/> for more information.
"Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont,
Jean-Michel Combes, 2-Jun-08, <draft-dupont-mipv6-rrcookie-06.txt>
This document defines a procedure which performs a "care-of address
test" using a state cookie for routing optimization in Mobile IPv6
not protected by the routing routability procedure, i.e., protected
by some alternative mechanisms like pre-shared secret or pre-
established IPsec security associations.
"Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg,
14-Jul-08, <draft-meadors-certificate-exchange-09.txt>
The EDIINT AS1, AS2 and AS3 message formats do not currently contain
any neutral provisions for transporting and exchanging trading
partner profiles or digital certificates. EDIINT Certificate Exchange
Messaging provides the format and means to effectively exchange
certificates for use within trading partner relationships. The
messaging consists of two types of messages, Request and Response,
which allow trading partners to communicate certificates, their intended
usage and their acceptance through XML. Certificates can be specified for
use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS).
"IPFIX Flow Aggregation", Falko Dressler, Christoph Sommer, Gerhard Muenz,
Atsushi Kobayashi, 14-Jul-08, <draft-dressler-ipfix-aggregation-05.txt>
IPFIX Flow Aggregation describes a methodology for reducing the
amount of measurement data exchanged between monitoring devices
(IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation
techniques represent a necessary enhancement in order to cope with
increasing amounts of monitoring data that accrue with the ever-
growing network capacities. Using Flow Selection Criteria and
Compound Flow creation techniques, measurement information of
multiple Flows that are sharing some common criteria is merged to be
exported in one Compound Flow. Subsets of Flows eligible for
aggregation, as well as the desired degree of similarity, can be
customized using a set of Aggregation Rules.
"VoIP Configuration Server Address Option", Richard Johnson, 8-Jul-08,
<draft-raj-dhc-tftp-addr-option-04.txt>
This memo documents existing usage for the "VoIP Configuration Server
Address Option" (previously known as the "TFTP Server IP Address
Option"). The option number currently in use is 150. This memo
documents the current usage of the option in agreement with
[RFC3942], which declares that any pre-existing usages of option
numbers in the range 128 - 223 should be documented and the working
group will try to officially assign those numbers to those options.
"Circuit Cross-Connect", Kireeti Kompella, 9-Feb-06,
<draft-kompella-ccc-02.txt>
Circuit Cross-Connect (CCC) was the ground-breaking design and
implementation of the transport of Layer 2 frames over Multi-Protocol
Label Switching (MPLS), which is now seen as an important application
of MPLS. Thus, documenting CCC is important from a historical point
of view. Furthermore, CCC is still in production in many networks,
providing yet another reason to document it. It is hoped that those
interested in this area will see where it started, how far we have
come, and the strengths and weaknesses of this particular approach,
and thereby gain some perspective of the area. If in the process
they get new insights for the future development in this area, that
is a bonus.
"Transmitting Confidential Data in RADIUS", Glen Zorn, Hao Zhou, Joseph
Salowey, 28-Oct-08, <draft-zorn-radius-encattr-15.txt>
This document defines a set of Type-Length-Value (TLV) tuples which,
when encapsulated in RADIUS Extended Attributes, are designed to
allow the secure transmission of sensitive or confidential data
(including encryption keys) between RADIUS clients and servers.
"The LDAP Don't Use Copy Control", Kurt Zeilenga, 13-Jul-08,
<draft-zeilenga-ldap-dontusecopy-06.txt>
This document defines the Lightweight Directory Access Protocol (LDAP)
Don't Use Copy control extension which allows a client to specify that
copied information should not be used in providing service. This
control is based upon the X.511 dontUseCopy service control option.
"Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning
Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07,
<draft-shacham-sipping-session-mobility-05.txt>
Session mobility is the transfer of media of an ongoing communication
session from one device to another. This document describes the
basic approaches and shows the signaling and media flow examples for
providing this service using the Session Initiation Protocol (SIP).
Service discovery is essential to locate targets for session transfer
and is discussed using the Service Location Protocol (SLP) as an
example. This document is intended as an informational document.
"SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service
and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh,
7-Jul-08, <draft-westerlund-mmusic-3gpp-sdp-rtsp-06.txt>
The Packet-switched Streaming Service (PSS) and the Multimedia
Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP
with some extensions. This document provides information about these
extensions and registers the RTSP and SDP extensions with IANA.
"Complications from Network Address Translator Deployment Topologies", Pyda
Srisuresh, Bryan Ford, 18-Oct-08, <draft-ford-behave-top-04.txt>
This document identifies two deployment scenarios that have arisen
from the unconventional network topologies formed using Network
Address Translator devices (NATs). First, the simplicity of
administering networks through the combination of NAT and DHCP has
increasingly lead to the deployment of multi-level inter-connected
private networks involving overlapping IP address spaces. Second,
the proliferation of private networks in enterprises, hotels and
conferences, and the wide spread use of Virtual Private Networks
(VPNs) to access enterprise intranet from remote locations has
increasingly lead to overlapping IP address space between remote
and corporate networks. The document does not dismiss these
unconventional scenarios as invalid, but recognizes them as real and
offers recommendations to ensure these real scenarios can funtion.
"P3P Policy Attributes for LDAP", Mark Wahl, 12-Dec-06,
<draft-wahl-ldap-p3p-03.txt>
This document defines attributes for use in the Lightweight Directory
Access Protocol (LDAP) which contain URIs for privacy policy
documents. These documents describe the privacy policy concerning
access to a directory server, and the privacy policies that apply to
the contents of the directory (a subtree of entries).
"Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07,
<draft-iino-capwap-wicop-02.txt>
The popularity of wireless local area networks (WLANs) has led to
wide spread deployments across different establishments. It has also
translated in to increasing scale of the WLANs. Large-scale
deployments made of large numbers of wireless termination points
(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document
allows for the control and provisioning of large-scale WLANs. It
enables central management of these networks and realizes the
objectives set forth for the control and provisioning of wireless
access points (CAPWAP).
"Multiple Attachments for EDI-INT", Kyle Meadors, 16-Jun-08,
<draft-meadors-multiple-attachments-ediint-06.txt>
The EDIINT AS1, AS2 and AS3 message were designed specifically for
the transport of EDI documents. Since multiple interchanges could be
placed within a single EDI document, there was not a need for sending multiple
EDI documents in a single message. As adoption of EDI-INT grew, other uses
developed aside from single EDI document transport. Some transactions required
multiple attachments to be interpreted together and stored in a single message.
This informational draft describes how multiple documents, including non-EDI
payloads, can be attached and transmitted in a single EDI-INT transport message.
The attachments are stored within the MIME Multipart/Related structure. A
minimal list of content-types to be supported as attachments is
provided.
"Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004",
Chih-Chang Hsu, 22-Jul-05, <draft-hsu-xcast-bcp-2004-01.txt>
In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a
protocol intended for small group multicasting. It combined three
similar datagram simulcasting protocols that were submitted as
earlier Internet Drafts by a number of different research groups.
After that, researchers in those groups worked together to further
develop, experiment and conduct standardization in IETF as well as in
the open source community. This resulted in several implementations
of protocol stacks, systems of multi-party video conference and group
management, and mechanisms for harmonizing XCAST with ASM and SSM. In
addition, an XCAST backbone for various experiments has been launched
to operate inter-continentally.
One of the main purposes of this document is to summarize the efforts
undertaken by XCAST community as "best current practices" that would
then be formally introduced to the IETF/IRTF community. In addition,
we raise an issue concerning IANA resource allocation, which prevents
us from widely expanding our experimental networks as well as
distributing our software. Finally, we request IESG and other experts
to check the validity of our proposed protocol and make any
suggestions about how IANA can assign appropriate resources
accordingly.
"SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06,
<draft-narasimhan-ietf-slapp-01.txt>
The CAPWAP problem statement [3] describes a problem that needs to be
addressed before a wireless LAN (WLAN) network designer can construct
a solution composed of Wireless Termination Points (WTP) and Access
Controllers (AC) from multiple, different vendors. One of the
primary goals is to find a solution that solves the interoperability
between the two classes of devices (WTPs and ACs) which then enables
an AC from one vendor to control and manage a WTP from another.
"An Extensible Format for Email Feedback Reports", Yakov Shafranovich, John
Levine, Paul Hoffman, Murray Kucherawy, 16-Jun-08,
<draft-shafranovich-feedback-report-05.txt>
This document defines an extensible format and MIME type that may be
used by network operators to report feedback about received email to
other parties. This format is intended as a machine readable
replacement for various existing report formats currently used in
Internet email.
"Registration Templates for Legacy Message Header Field Names", Bruce Lilly,
21-Apr-05, <draft-lilly-legacy-fields-00.txt>
This memo documents several Internet Message Format message header
field names and provides registration templates so that the names can
be registered in the permanent message header field name registry.
"The 'news' and 'nntp' URI Schemes", Frank Ellermann, 2-Apr-08,
<draft-ellermann-news-nntp-uri-11.txt>
This memo specifies the 'news' and 'nntp' Uniform Resource Identifier
(URI) schemes that were originally defined in RFC 1738. The purpose
of this document is to allow RFC 1738 to be made obsolete while
keeping the information about these schemes on standards track.
"IMMP -- Internet Message Mapping Protocol", Sabarish Ramanathan, 24-May-05,
<draft-sabarish-immp-01.txt>
The Internet Message Mapping Protocol (IMMP) is designed to support
the provision of mail in a medium to large scale operation. It is
intended to be used as a companion to the SMTP protocol and mail
receiving protocols (POP, IMAP, web mail also), providing services
which are outside the scope of mail access. The services that IMMP
provides are mapping mails into appropriate subinbox (inside the
inbox) when the messages are received through SMTP, Extended inbox
management and Spam guard management.
"CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux,
3-Nov-08, <draft-desruisseaux-caldav-sched-06.txt>
This document defines extensions to the CalDAV calendar-access
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components. This document
defines the "calendar-auto-schedule" feature of CalDAV.
"Bundle Security Protocol Specification", Susan Symington, Stephen Farrell,
Howard Weiss, Peter Lovell, 2-Nov-08,
<draft-irtf-dtnrg-bundle-security-06.txt>
This document defines the bundle security protocol, which provides
data integrity and confidentiality services. We also describe
various bundle security considerations including policy options.
"Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki,
Arifumi Matsumoto, Shirou Niinobe, Ruri Hiromi, Ken-ichi Kanayama, 3-Jun-08,
<draft-fujisaki-dhc-addr-select-opt-06.txt>
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.
"Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand,
31-Oct-08, <draft-bryant-shand-lf-applicability-06.txt>
This draft describes the applicability of loop free convergence
technologies to a number of network applications.
"Using non-ASCII Characters in RFCs", Tim Bray, Paul Hoffman, 3-Nov-08,
<draft-hoffman-utf8-rfcs-04.txt>
This document specifies a change to the IETF process in which
Internet Drafts and RFCs are allowed to contain non-ASCII characters.
The proposed change is to change the encoding of Internet Drafts and
RFCs to UTF-8.
"Security Extension for Unidirectional Lightweight Encapsulation Protocol",
Prashant Pillai, 14-Jul-08, <draft-cruickshank-ipdvb-sec-05.txt>
This document describes the header extension for Unidirectional
Encapsulation Protocol (ULE) that secures the IP traffic
transported using ULE to provide security features like data
confidentiality, data integrity, data origin authentication and
mechanisms to prevent replay attacks. The format of the header
extension and processing at the Receiver and Transmitter are
described in detail.
"QoS-Enhanced Border Gateway Protocol", Mohammed Boucadair, 5-Jul-05,
<draft-boucadair-qos-bgp-spec-01.txt>
This memo describes a proposal for exchanging QoS-enabled
reachability information between service providers. It defines new
BGP attributes to be used in order to convey QoS performance
characteristics between service providers and it describes how to use
these QoS values in order to select the best path. An example of
route selection process that takes into account the QoS performance
values enclosed in BGP messages is also detailed.
"The Meta-QoS-Class concept", Pierre Levis, Mohammed Boucadair, 30-Jun-05,
<draft-levis-meta-qos-class-00.txt>
This document describes a framework for inter-domain Quality of
Service (QoS). It makes use of a new concept denoted by Meta-QoS-
Class. This new concept guides and simplifies QoS agreements between
providers and opens up new perspectives for a global QoS-enabled
Internet.
"Applicability of Reliable Server Pooling for Real-Time Distributed
Computing", Thomas Dreibholz, 11-Jul-08,
<draft-dreibholz-rserpool-applic-distcomp-05.txt>
This document describes the applicability of the Reliable Server
Pooling architecture to manage real-time distributed computing pools
and access the resources of such pools.
"RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul
Congdon, Joseph Salowey, 31-Oct-08, <draft-aboba-radext-wlan-09.txt>
RFC 3580 provides guidelines for the use of the Remote Authentication
Dialin User Service (RADIUS) within IEEE 802 local area networks
(LANs). This document proposes additional attributes for use within
IEEE 802 networks. The attributes defined in this document are
usable both within RADIUS and Diameter.
"Use of the Reason header filed in Session Initiation Protocol (SIP)
responses", Roland Jesske, Martin Huelsemann, 7-Oct-08,
<draft-jesske-sipping-etsi-ngn-reason-04.txt>
This document proposes the use of the Reason header field in SIP
responses.
"Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris
Cross, 31-Jul-07, <draft-engelsma-dmsp-04.txt>
This document proposes a Distributed Multimodal Synchronization
Protocol (DMSP) designed to enable multimodal interaction for mobile
devices by accessing services in the network. More specifically,
this protocol coordinates events of interest between a visual browser
or application running on a mobile device with a VoiceXML (Voice
Extensible Markup Language) browser running in the network.
"Dynamic Provisioning using Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, David
McGrew, Joseph Salowey, Hao Zhou, 31-Oct-08,
<draft-cam-winget-eap-fast-provisioning-10.txt>
The flexible authentication via secure tunneling EAP method (EAP-
FAST) enables secure communication between a peer and a server by
using Transport Layer Security (TLS) to establish a mutually
authenticated tunnel. EAP-FAST also enables the provisioning
credentials or other information through this protected tunnel. This
document describes the use of EAP-FAST for dynamic provisioning.
"Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz,
11-Jul-08, <draft-hohendorf-secure-sctp-05.txt>
This document explains the reason for the integration of security
functionality into SCTP, and gives a short description of S-SCTP and
its services. S-SCTP is fully compatible with SCTP defined in
RFC2960, it is designed to integrate cryptographic functions into
SCTP.
"General Area Review Team (GenART) Experiences", Mary Barnes, Avri Doria,
Harald Alvestrand, Brian Carpenter, 14-Aug-08,
<draft-doria-genart-experience-02.txt>
The General Area Review team has been doing Reviews of Internet
Drafts since 2004. This draft discusses the experience and the
lessons learned over the past 4+ years of this process. The review
team initially did reviews before each of the IESG telechats.
Beginning in late 2005, review team members have been assigned to
review documents during IETF Last Call, unless no IETF Last Call is
necessary for the document. The same reviewer then reviews any
updates when the document is placed on an IESG telechat agenda.
"Survey of IP address autoconfiguration mechanisms for MANETs", Carlos
Bernardos, Maria Calderon, Hassnaa Moustafa, 1-Nov-08,
<draft-bernardos-manet-autoconf-survey-04.txt>
This Internet Draft provides a detailed description of most of the
existing IP autoconfiguration solutions proposed so far. The main
aim of this document is to serve as a general reference for the
AUTOCONF solution space. We present most of the previously proposed
IP AUTOCONF mechanisms in MANETs, showing their key characteristics,
conforming to the AUTOCONF problem statement draft and the MANET
architecture draft. Furthermore, each solution is analysed based on
a number of evaluation considerations.
"Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08,
<draft-urpalainen-simple-presence-relaxng-05.txt>
This memo describes a batch of Presence Information Data Format
(PIDF) and its extension schemas written with the RELAX NG schema
language. Unlike with the current W3C XML Schema language it is
possible to write reasonable forwards and backwards compatible
presence combination schemas. These RELAX NG schemas are stricter
than the W3C Schemas and thus the instance documents that validate
with these schemas follow the intended content model more closely.
Especially, these schemas are targeted to actual implementations in
order to decrease interoperability problems.
"BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart,
17-Nov-08, <draft-scudder-bmp-01.txt>
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.
"Operational Reliability for EDIINT AS2 draft-duker-as2-reliability-04.txt",
Intellectual Property, 4-Sep-08, <draft-duker-as2-reliability-04.txt>
The goal of this document is to define approaches to achieve a "once
and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is
implemented by a number of software tools on a variety of platforms
with varying capabilities and with varying network service quality.
Although the AS2 protocol defines a unique "Message-ID", current
implementations of AS2 do not provide a standard method to prevent
the same message (re-transmitted by the initial sender) from reaching
back-end business applications at the initial receiver. TCP
underpinnings of HTTP over which AS2 operates generally provide a
good quality of network connectivity, but experience indicates a need
to be able to compensate for both transient server and socket
exceptions, including "Connection refused" as well as "Server busy."
In addition, difficulties with server availability, stability, and
loads can result in reduced operational reliability. This document
describes some ways to compensate for exceptions and enhance the
reliability of AS2 protocol operation. Implementation of these
reliability features is indicated by presence of the "AS2-
Reliability" value in the EDIINT-Features header.
"Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels", Fred Templin,
14-May-07, <draft-templin-linkadapt-06.txt>
IPv6-in-(foo)*-in-IPv4 tunnels must support a minimum Maximum
Transmission Unit (MTU) of 1280 bytes for IPv6 via static
prearrangements and/or dynamic MTU determination based on ICMPv4
messages, but these methods have known operational limitations. This
document specifies a link adaptation mechanism for IPv6-in-(foo)*-in-
IPv4 tunnels that presents an assured MTU to the IPv6 layer using
tunnel endpoint-based segmentation/reassembly and dynamic segment
size probing.
"EDI-INT Features Header", Kyle Meadors, 1-Oct-08,
<draft-meadors-ediint-features-header-05.txt>
With the maturity of the EDI-INT standard of AS1, AS2 and AS3,
applications and additional features are being built upon the basic
secure transport functionality. These features are not necessarily
supported by all EDI-INT applications and could cause potential
problems with implementations.
"HIP DHT Interface", Jeff Ahrenholz, 7-Oct-08,
<draft-ahrenholz-hiprg-dht-03.txt>
This document specifies a common interface for using HIP with a
Distributed Hash Table service to provide a HIT-to-address lookup
service and an unmanaged name-to-HIT lookup service.
"Enhanced Fast Handover for Mobile IPv6 based on IEEE 802.11 Network",
Youngsong Mun, 27-Oct-08, <draft-mun-mipshop-efh-fast-mipv6-02.txt>
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.
"Delay-Tolerant Networking Security Overview", Stephen Farrell, Susan
Symington, Howard Weiss, Peter Lovell, 2-Nov-08,
<draft-irtf-dtnrg-sec-overview-05.txt>
This document provides an overview of the security requirements and
mechanisms considered for delay tolerant networking security. It
discusses the options for protecting such networks and describes
reasons why specific security mechanisms were (or were not) chosen
for the relevant protocols. The entire document is informative,
given its purpose is mainly to document design decisions.
"Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg,
Zachary Zeltsan, Alec Brusilovsky, 9-Oct-08, <draft-brusilovsky-pak-07.txt>
This document proposes to add mutual authentication, based on
human-memorizable password, to the basic unauthenticated Diffie-Hellman
key exchange. The proposed algorithm is called Password-authenticated
Key exchange (PAK). PAK allows two parties to authenticate themselves
while performing the Diffie-Hellman exchange.
The protocol is secure against all passive and active attacks.
In particular, it does not allow either type of attackers to obtain any
information that would enable an off-line dictionary attack on the
password. The use of Diffie-Hellman exchange ensures Forward Secrecy.
"Moving Forwards with IETF Process Evolution", Elwyn Davies, 26-Oct-06,
<draft-davies-pesci-initial-considerations-03.txt>
This document provides a summary of previously identified problems
with the Internet Engineering Task Force (IETF) process for
developing standards and other specifications; and then identifies a
set of goals to aim at, and guidelines that should be followed during
any activity seeking to revise and update this process. It does not
propose specific changes to the process, which should be the subject
of future documents.
"Private Header (P-Header) Extensions to the Session Initiation Protocol
(SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage,
14-Jul-08, <draft-drage-sipping-rfc3455bis-01.txt>
This document describes a set of private Session Initiation Protocol
(SIP) headers (P-headers) used by the 3rd-Generation Partnership
Project (3GPP), along with their applicability, which is limited to
particular environments. The P-headers are for a variety of purposes
within the networks that the partners use, including charging and
information about the networks a call traverses.1. Overall Applicability
The SIP extensions specified in this document make certain
assumptions regarding network topology, linkage between SIP and lower
layers, and the availability of transitive trust. These assumptions
are generally NOT APPLICABLE in the Internet as a whole. The
mechanisms specified here were designed to satisfy the requirements
specified in the 3GPP Release 5 requirements on SIP [RFC4083] for
which either no general-purpose solution was planned, where
insufficient operational experience was available to understand if a
general solution is needed, or where a more general solution is not
yet mature. For more details about the assumptions made about these
extensions, consult the Applicability subsection for each extension.2. Conventions
"Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 25-Jun-08,
<draft-haddad-alien-privacy-terminology-04.txt>
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.
"Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob
Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 4-Aug-08,
<draft-briscoe-tsvwg-re-ecn-tcp-06.txt>
This document introduces a new protocol for explicit congestion
notification (ECN), termed re-ECN, which can be deployed
incrementally around unmodified routers. It enbales the the upstream
party at any trust boundary in the internetwork to be held
responsible for the congestion they cause, or allow to be caused.
So, networks can introduce straightforward accountability for
congestion and policing mechanisms for incoming traffic from end-
customers or from neighbouring network domains. 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 also gives examples of
mechanisms that can use the protocol to ensure data sources respond
correctly to congestion. And it describes example mechanisms that
ensure the dominant selfish strategy of both network domains and end-
points will be to set the extended ECN field honestly.
"Considerations for Having a Successful BOF", Thomas Narten, 12-Oct-07,
<draft-narten-successful-bof-03.txt>
This document discusses tactics and strategy for hosting a successful
IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the
formation of an IETF Working Group. It is based on the experiences of
having participated in numerous BOFs, both successful and
unsuccessful.
"Carrying Attached Addresses in IS-IS", David Ward, Russ White, Dino
Farinacci, Ayan Banerjee, Radia Perlman, 3-Nov-08, <draft-ward-l2isis-04.txt>
This draft specifies the IS-IS extensions necessary to support multi-
link IPv4 and IPv6 networks, as well as to provide true link state
routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.1. Overview
There are a number of systems (for example, [RBRIDGES]) which have
proposed using layer 2 addresses carried in a link state routing
protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
2 routing in specific environments. This draft proposes a set of
TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new
PDU types, to support these proposed systems.
This draft does not propose new forwarding mechanisms using this
additional information carried within IS-IS. There is a short
section included on two possible ways to build a shortest path first
tree including this information, to illustrate how this information
might be used.
"IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed
Guy, Frank Miller, Kenneth Shumard, 5-Oct-08, <draft-guy-iax-05.txt>
This document describes IAX, the Inter-Asterisk eXchange protocol, an
application-layer control and media protocol for creating, modifying,
and terminating multimedia sessions over Internet Protocol (IP)
networks. IAX was developed by the open source community for the
Asterisk PBX and is targeted primarily at Voice over Internet
Protocol (VoIP) call control, but it can be used with streaming video
or any other type of multimedia.
IAX is an "all in one" protocol for handling multimedia in IP
networks. It combines both control and media services in the same
protocol. In addition, IAX uses a single UDP data stream on a static
port greatly simplifying Network Address Translation (NAT) gateway
traversal, eliminating the need for other protocols to work around
NAT, and simplifying network and firewall management. IAX employs a
compact encoding which decreases bandwidth usage and is well suited
for Internet telephony service. In addition, its open nature permits
new payload types additions needed to support additional services.
"DTCP: Dynamic Tasking Control Protocol", David Cavuto, 19-Nov-08,
<draft-cavuto-dtcp-02.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.
"Operational issues with Tiny Fragments in IPv6", Vishwas Manral, 9-Sep-08,
<draft-manral-v6ops-tiny-fragments-issues-03.txt>
IPv6 fragmentation allows fragments to be sent only by the source of
a packet. The Fragment header is used by an IPv6 source to send a
packet larger than would fit in the path MTU to its destination.
Firewalls generally use 5-tuples to filter out packets. However there
are cases where fragmentation can be used to disguise TCP packets
from IP filters used in routers and hosts. This document specifies
where tiny fragments can be issues.
"SIP Interface to VoiceXML Media Services", Dave Burke, 12-Jul-07,
<draft-burke-vxml-03.txt>
This document describes a SIP interface to VoiceXML media services,
which is commonly employed between application servers and media
servers offering VoiceXML processing capabilities.
"Extending ICMP for Interface and Next-hop Identification", Alia Atlas,
Ronald Bonica, Nuova Systems, Naiming Shen, Enke Chen, 3-Nov-08,
<draft-atlas-icmp-unnumbered-06.txt>
This memo defines ICMP extensions, using ICMP multi-part messages,
through which a router or host can explicitly identify an interface
by ifIndex, name, and/or address, as already used in MIBs and by
OSPF. The interfaces so identified can be the interface upon which
an undeliverable datagram arrived, a sub-IP member of that interface,
and the interface through which the datagram would have been sent.
The nexthop IP address can also be provided as part of the outgoing
interface information. The extensions defined herein are
particularly useful when troubleshooting networks with unnumbered
interfaces, parallel interfaces and/or asymmetric routing.
"Key Management through Key Continuity (KCM)", Peter Gutmann, 29-Sep-08,
<draft-gutmann-keycont-01.txt>
This memo provides advice and Best Current Practice for implementors
and deployers of security applications that wish to use the key
continuity method of key management.
"Private Extensions to the Session Initiation Protocol (SIP) for Service
Interaction Indicator", Yuzhong Shen, 28-May-08,
<draft-shen-interaction-ind-04.txt>
In SIP-based networks, a SIP session MAY involve several application
servers on the originating and terminating side. In a certain case,
an application server needs to set some indications in SIP message to
indicate service information (what are invoked, what can be allowed
and what should blocked). This kind of information will be also
required for composition of SIP applications. There is a need to
provide indicators for service interaction between SIP application
servers or other SIP endpoints.
This document describes a mechanism of service interaction indicator
for the Session Initiation Protocol (SIP) that enhances service
interaction between SIP application servers in a trusted network.
"The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 7-Aug-08,
<draft-shur-pack-uri-scheme-04.txt>
A package is a logical entity that holds a collection of parts.
Given the URI for a complete package, the "pack" URI scheme provides
for the construction and use of URIs referring to individual parts
within the package. It also provides for the use of part's URIs as
base URIs for resolving relative references between the parts in a
single package.
"Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ
Housley, 10-Sep-07, <draft-housley-tls-authz-extns-07.txt>
This document specifies authorization extensions to the Transport
Layer Security (TLS) Handshake Protocol. Extensions carried in the
client and server hello messages to confirm that both parties support
the desired authorization data types. Then, if supported by both the
client and the server, authorization information is exchanged in the
supplemental data handshake message.
"LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark,
14-Jul-08, <draft-chakrabarti-6lowpan-ipv6-nd-05.txt>
IETF 6LowPan working group defines IPv6 over low-power personal area
network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have
multicast support, although it supports broadcast. Due to the nature
of LowPan network or sensor networks, broadcast messages should be
minimized. This document suggests some optimizations to IPv6
Neighbor Discovery related multicast messages in order to reduce
signaling in the low-cost low-powered network.
"BR Organization Mapping for the Extensible Provisioning Protocol (EPP)",
Frederico Neves, Hugo Koji Kobayashi, 24-Aug-06,
<draft-neves-epp-brorg-03.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of .br
organizational social information stored in a shared central
repository. Specified in XML, this mapping extends the EPP contact
mapping to provide additional features required for the provisioning
of .br organizational social information.
"The Qpopper MIME Mangling and Macro Extensions to POP3", Randall Gellens,
17-Nov-08, <draft-gellens-pop-mangle-02.txt>
This document describes two extensions to the POP protocol that have
been supported for several years by some client and servers. One
extension, MANGLE, allows clients to request that MIME body parts be
removed or converted to a simpler format, that only selected headers
be transmitted, and/or for the message to be transcoded to a
different character set. The other extension, MACRO, allows clients
to define macros which are expanded when used, saving repetitive
transmissions.
The MANGLE extension has been useful in at least two situations: it
allows clients on constrained devices to avoid downloading body
parts which cannot be used on the device, and clients which use the
TOP command to "peek" at messages can have the preview transformed
into more usable content, as well as avoiding the transmission of
undesired headers. The MACRO extension has been especially useful
in conjunction with MANGLE, since a MANGLE request can become
relatively lengthy.
"WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 4-Aug-08,
<draft-leung-mip4-proxy-mode-09.txt>
Mobile IPv4 is a standard mobility protocol that enables IPv4 device
to move among networks while maintaining its IP address. The mobile
device has the Mobile IPv4 client function to signal its location to
the routing anchor, known as the Home Agent. However, there are many
IPv4 devices without such capability due to various reasons. This
document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on
having the Mobile IPv4 client function in a network entity to provide
mobility support for an unaltered and mobility-unaware IPv4 device.
This document also describes a particular application of PMIPv4 as
specified in the WiMAX Forum and another application that is to be adopted
in 3GPP2.
"Media Server Markup Language (MSML)", Adnan Saleem, 14-Aug-08,
<draft-saleem-msml-07.txt>
The Media Server Markup Language (MSML) is used to control and invoke
many different types of services on IP Media Servers. Clients can use
it to define how multimedia sessions interact on a Media Server and
to apply services to individuals or groups of users. MSML can be
used, for example, to control Media Server conferencing features such
as video layout and audio mixing, create sidebar conferences or personal
mixes, and set the properties of media streams. As well, clients can use
MSML to define media processing dialogs, which may be used as parts of application
interactions with users or conferences. Transformation of media streams to
and from users or conferences as well as IVR dialogs are examples of such
interactions, which are specified using MSML. MSML clients may also invoke
dialogs with individual users or with groups of conference participants using
VoiceXML.
"PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, Adrian
Farrel, Intellectual Property, 15-Oct-08, <draft-yasukawa-pce-vpn-req-05.txt>
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
An important application of MPLS and GMPLS networks is Virtual
Private Networks (VPNs) that may be constructed using Label Switched
Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may
be applied as a tool to compute the paths of such tunnels in order to
achieve better use of the network resources and to provide better
levels of service to the VPN customers.
Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in "Path
Computation Element (PCE) Communication Protocol Generic
Requirements". This document complements the generic requirements and
presents a detailed set of PCC-PCE communication protocol
requirements that are specific to the application of PCE to VPNs.
"Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label
Switching Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 15-Oct-08,
<draft-yasukawa-mpls-mp2p-rsvpte-05.txt>
Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses
Resource Reservation Protocol traffic engineering extensions
(RSVP-TE) as the signaling protocol to establish Label Switched Paths
(LSPs). Although the Resource Reservation Protocol (RSVP) on which
RSVP-TE is built supports the convergence of traffic flows toward a
common destination, this concept has not been exploited in MPLS-TE
which has been limited to point-to-point (P2P) and
point-to-multipoint (P2MP) LSPs.
This document describes extensions to RSVP-TE procedures and protocol
elements to support multipoint-to-point (MP2P) LSPs.
"Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli,
2-Nov-08, <draft-irtf-mobopts-location-privacy-solutions-10.txt>
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable
while it roams on the Internet. However, the location and movement
of the mobile node can be revealed by IP addresses used in signaling
or data packets. In this document, we consider the Mobile IPv6
location privacy problem described in RFC 4882, and propose efficient
and secure techniques to protect location privacy of the mobile node.
This document is a product of the IP Mobility Optimizations (MobOpts)
Research Group.
"Organizing IETF Process Change", Elwyn Davies, 13-Jun-06,
<draft-davies-pesci-next-steps-01.txt>
This document sets out a strawman proposal for how to organize the
revision and update of any part of the Internet Engineering Task
Force (IETF) processes including those for developing standards and
other specifications. It does not propose specific changes to any of
these processes, which should be the subject of future documents.
However, it does propose an initial target area for process change.
"Authorization for NSIS Signaling Layer Protocols", Jukka Manner, Martin
Stiemerling, Hannes Tschofenig, Roland Bless, 2-Jul-08,
<draft-manner-nsis-nslp-auth-04.txt>
Signaling layer protocols in the NSIS working group may rely on GIST
to handle authorization. Still, the signaling layer protocol 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.
"Enhanced validation of domains for HTTP State Management Cookies using DNS",
Yngve Pettersen, 3-Nov-08, <draft-pettersen-dns-cookie-validate-04.txt>
HTTP State Management Cookies are used for a wide variety of tasks on
the Internet, from preference handling to user identification. An
important privacy and security feature of cookies is that their
information can only be sent to a servers in a limited namespace, the
domain.
The variation of domain structures that are in use by domain name
registries, especially the country code Top Level Domains (ccTLD)
namespaces, makes it difficult to determine what is a valid domain,
e.g. example.co.uk and example.no, which cookies should be permitted
for, and a registry-like domain (subTLDs) like co.uk where cookies
should not be permitted.
This document specifies an imperfect method using DNS name lookups
for cookie domains to determine if cookies can be permitted for that
domain, based on the assumption that most subTLD domains will not
have an IP address assigned to them, while most legitimate services
that share cookies among multiple servers will have an IP address for
their domain name to make the user's navigation easier by omitting
the customary "www" prefix.
"The TLD Subdomain Structure Protocol and its use for Cookie domain
validation", Yngve Pettersen, 3-Nov-08,
<draft-pettersen-subtld-structure-04.txt>
This document defines a protocol and specification format that can be
used by a client to discover how a Top Level Domain (TLD) is
organized in terms of what subdomains are used to place closely
related but independent domains, e.g. commercial domains in country
code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain.
This information is then used to limit which domains an Internet
service can set cookies for, strengthening the rules already defined
by the cookie specifications.
"ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan
Johnston, Jon Callas, 24-Oct-08, <draft-zimmermann-avt-zrtp-10.txt>
This document defines ZRTP, a protocol for media path Diffie-Hellman
exchange to agree on a session key and parameters for establishing
Secure Real-time Transport Protocol (SRTP) sessions. 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.
"Definition of an Internet Research Task Force (IRTF) Document Stream", Aaron
Falk, 22-Sep-08, <draft-irtf-rfcs-03.txt>
This memo defines the publication stream for RFCs from the Internet
Research Task Force. Most documents undergoing this process will
come from IRTF Research Groups and it is expected that they will be
published as Informational or Experimental RFCs by the RFC Editor.
"DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy,
27-May-08, <draft-hayatnagarkar-dnsext-validator-api-06.txt>
The DNS Security Extensions (DNSSEC) provide origin authentication
and integrity of DNS data. However, the current resolver Application
Programming Interface (API) does not specify how a validating stub
resolver should communicate detailed results of DNSSEC processing
back to the application. This document describes an API between
applications and a validating stub resolver that allows applications
to control the DNSSEC validation process and obtain results of DNSSEC
processing.
"Channel Bindings for TLS based on PRF", Simon Josefsson, 12-Aug-08,
<draft-josefsson-sasl-tls-cb-01.txt>
This document specify how to compute data, "channel bindings", that
is cryptographically bound to a specific Transport Layer Security
(TLS) session. The intention is to use this data as a name of the
secure channel for the purpose of a channel binding. The channel
bindings can be used by authentication protocols to avoid tunneling
attacks and security layer re-use. The data is derived using the TLS
Pseudo-Random Function (PRF).
"Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility",
Thomas Dreibholz, Jobin Pulinthanath, 11-Jul-08,
<draft-dreibholz-rserpool-applic-mobility-04.txt>
This document describes a novel mobility concept based on a
combination of SCTP with Dynamic Address Reconfiguration extension
and Reliable Server Pooling (RSerPool).
"Fast Initial OSPFv2 LSDB Synchronization for BMA", Mitchell Erblich,
27-Mar-06, <draft-erblich-fast-init-lsdb-synch-bma-00.txt>
This memo documents a feature that significantly decreases
the initial LSDB synchronization time in Broadcast Multiple
Access (BMA) environments. This implementation only requires
a single OSPF speaker per psuedo-node to support this
functionality. These changes are implicitly supported within
the OSPFv2 protocol. This memo is not intended to serve as a
model for any other implementation.
"Limited IP Header Compression over PPP", Janusz Jurski, 8-Mar-07,
<draft-jurski-pppext-iphc-02.txt>
The negotiation options specified in RFC 2509 defined an
all-or-nothing strategy for applying header compression: peers were
assumed to support compression for any combination of headers.
[RFC3544] refined that strategy to make it possible to negotiate
header compression for only TCP or only non-TCP packets (and also
added Enhanced RTP-Compression negotiation option). The current
document further refines the strategy by also making it possible to
negotiate header compression for only particular combinations of
headers or header types.
"Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz,
Michael Tuexen, 11-Jul-08, <draft-dreibholz-rserpool-score-03.txt>
This memo describes some of the scoring to be used in the testing of
Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
"MPLS Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 7-Jul-08,
<draft-akhter-bmwg-mpls-meth-04.txt>
The purpose of this draft is to describe a methodology specific to
the benchmarking of MPLS forwarding devices. The scope of this
benchmarking will be limited to various types of packet-forwarding
and delay measurements. It builds upon the tenets set forth in
RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking
Methodology Working Group (BMWG) efforts. This document seeks to
extend these efforts to the MPLS paradigm.
"Requirements for Web Authentication Resistant to Phishing", Sam Hartman,
18-Aug-08, <draft-hartman-webauth-phishing-09.txt>
This memo proposes requirements for protocols between web browsers
and relying parties at websites; these requirements also impact third
parties involved in the authentication process. These requirements
minimize the likelihood that criminals will be able to gain the
credentials necessary to impersonate a user or be able to
fraudulently convince users to disclose personal information. To
meet these requirements browsers must change. Websites must never
receive information such as passwords that can be used to impersonate
the user to third parties. Browsers should authenticate the website
to the browser as part of authenticating the user to the website.
Browsers MUST flag situations when this authentication fails and flag
situations when the target website is not authorized to accept the
identity being offered as this is a strong indication of fraud.
These requirements may serve as a basis for requirements for
preventing fraud in environments other than the web.
"The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header
(P-Header)", Jani Hautakorpi, Gonzalo Camarillo, 12-Nov-07,
<draft-hautakorpi-sipping-uri-list-handling-refused-03.txt>
This document specifies the Session Initiation Protocol (SIP)
P-Refused-URI-List Private-Header (P-Header). This P-Header is used
in the Open Mobile Alliance's (OMA) Pust to talk over Cellular (PoC)
system. It enables URI-list servers to refuse the handling of
incoming URI-list that have embedded URI-lists. This P-Header also
makes it possible for the URI-list server to inform the client about
the embedded URI-list that caused the rejection and the individual
URIs that form such a URI-list.
"Terminology for Benchmarking Session Initiation Protocol (SIP) Networking
Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 3-Nov-08,
<draft-poretsky-sip-bench-term-05.txt>
This document provides a terminology for benchmarking SIP performance
in networking devices. Terms are included for test components, test
setup parameters, and performance benchmark metrics for black-box
benchmarking of SIP networking devices. The performance benchmark
metrics are obtained for the SIP control plane and media plane. The
terms are intended for use in a companion methodology document for
complete performance characterization of a device in a variety of
conditions making it possible to compare performance of different
devices. It is critical to provide test setup parameters and a
methodology document for SIP performance benchmarking because SIP
allows a wide range of configuration and operational conditions that
can influence performance benchmark measurements. It is necessary to
have terminology and methodology standards to ensure that reported
benchmarks have consistent definition and were obtained following the
same procedures. Benchmarks can be applied to compare performance of
a variety of SIP networking devices.
"A Profile for Resource Certificate Repository Structure", Geoff Huston,
Robert Loomans, George Michaelson, 22-Jun-08,
<draft-huston-sidr-repos-struct-02.txt>
This document defines a profile for the structure of repositories
that contain X.509 / PKIX Resource Certificates, Certificate
Revocation Lists and signed objects. This profile contains the
proposed object naming scheme, the contents of repository publication
points, the contents of publication point manifests and a possible
internal structure of a Repository Cache that is intended to
facilitate synchronization across a distributed collection of
repositories and facilitate certificate path construction.
"Virtual Enterprise Traversal (VET)", Fred Templin, 17-Nov-08,
<draft-templin-autoconf-dhcp-21.txt>
Enterprise networks connect routers over various link types, and may
also connect to provider networks and/or the global Internet. Nodes
in enterprise networks must have a way to automatically provision IP
addresses/prefixes and other information, and must also support post-
autoconfiguration operations even for highly-dynamic networks. This
document specifies a Virtual Enterprise Traversal (VET) abstraction
for autoconfiguration and operation of nodes in enterprise networks.
"Diameter Routing Extensions", Tina Tsou, Victor Fajardo, Jouni Korhonen,
Tolga Asveren, 29-Jul-08, <draft-tsou-dime-base-routing-ext-04.txt>
This document describes two(2) extensions to the current diameter
routing scheme. The first extension describes an explicit routing
mechanism that MAY be employed by Diameter nodes to allow specific
stateful Diameter proxies to remain in the path of all messages
exchanges constituting a Diameter session. The second extension
describes a realm based redirection scheme as an alternative to host
based redirection described in [RFC3588].
"Modes of Operation for Camellia for Use With IPsec", Akihiro Kato, Masayuki
Kanda, 5-Aug-08, <draft-kato-ipsec-camellia-modes-09.txt>
This document describes the use of the Camellia block cipher
algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode,
and Counter with CBC-MAC (CCM) mode, as an IKEv2 and Encapsulating
Security Payload (ESP) mechanism to provide confidentiality, data
origin authentication, and connectionless integrity.
"Secure Beacon: Securely Detecting a Trusted Network", Yaron Sheffer, Yoav
Nir, 21-Jan-08, <draft-sheffer-ipsec-secure-beacon-03.txt>
Remote access clients, in particular IPsec-based ones, are heavily
deployed in enterprise environments. In many enterprises the
security policy allows remote-access clients to switch to unprotected
operation when entering the trusted network. This document specifies
a method that lets a client detect this situation in a secure manner,
with the help of a security gateway. We propose a minor extension to
IKEv2 to achieve this goal.
"The LDAP Relax Rules Control", Kurt Zeilenga, 14-Jul-08,
<draft-zeilenga-ldap-relax-03.txt>
This document defines the Lightweight Directory Access Protocol (LDAP)
Relax Rules Control which allows a directory user agent (a client) to
request the directory service temporarily relax enforcement of various
data and service model rules.
"HTTP Header Linking", Mark Nottingham, 2-Jul-08,
<draft-nottingham-http-link-header-02.txt>
This document clarifies the status of the Link HTTP header and
attempts to consolidate link relations in a single registry.
"Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for
Supporting the PacketCable Distributed Call Signaling Architecture", Flemming
Andreasen, Bernie McKibben, Bill Marshall, 3-Nov-08,
<draft-andreasen-sipping-rfc3603bis-06.txt>
In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys customer-specific information and expectations about the
parties involved in the call. This document describes private
extensions to the Session Initiation Protocol (SIP) [RFC3261] for
supporting the exchange of customer information and billing
information between trusted entities in the PacketCable Distributed
Call Signaling Architecture. These extensions provide mechanisms for
access network coordination to prevent theft of service, customer
originated trace of harassing calls, support for operator services
and emergency services, and support for various other regulatory
issues. The use of the extensions is only applicable within closed
administrative domains, or among federations of administrative
domains with previously agreed-upon policies where coordination of
charging and other functions is required.
"DHCP Option for LDAP Directory Services discovery", Giuseppe Paterno,
28-Sep-06, <draft-gpaterno-dhcp-ldap-03.txt>
This document defines an experimental DHCP option for delivering
configuration information for LDAP services. Through this option, the
client receives an LDAP URL [8] of the closest available LDAP
server/replica that can be used to authenticate users or look up any
useful data.
"Definitions for TCP Connection Metrics", Terry Brugger, 17-Aug-06,
<draft-brugger-connection-metrics-01.txt>
Numerous metrics, or features, have been used to describe TCP
connections. These features are frequently of interest to the network
intrusion detection community, and occasionally the network
engineering community. While researchers may understand these terms
when used by others, there are no formal definitions of these terms
such that two researchers looking at the same connection will
necessarily calculate the same values for all the metrics. This paper
will propose a potential set of connection metrics with formal
definitions of each.
"Device Capability Negotiation for Device-Based Location Determination and
Location Measurements in HELD", Martin Thomson, James Winterbottom, 3-Jul-08,
<draft-thomson-geopriv-held-capabilities-04.txt>
A framework for the exchange of capabilities in HELD is described.
Capabilities for enabling device-based measurements and device-based
location generation are described.
"Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington,
Robert Durst, Keith Scott, 31-Oct-08,
<draft-symington-dtnrg-bundle-multicast-custodial-05.txt>
This document defines optional extensions to the Bundle Protocol [2]
for supporting the custodial multicast delivery of bundles within a
Delay-Tolerant Network (DTN). The protocol extensions described
herein may be used to support custody transfer and custody-based
reforwarding during the transmission of a bundle from a single source
node to multiple destination nodes.
"Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", Susan Symington,
Robert Durst, Keith Scott, 31-Oct-08,
<draft-irtf-dtnrg-bundle-encapsulation-04.txt>
This document defines an extension block that may be used with the
Bundle Protocol [2] within the context of a Delay-Tolerant Network
architecture [6]. When included as part of a given bundle B, this
extension block, called a Bundle-in-Bundle Encapsulation Block,
indicates that one or more other bundles have been placed inside of
the payload field of B's Bundle Payload Block according to the format
defined in this document. Hence, the Bundle-in-Bundle Encapsulation
Block provides a mechanism for bundle-in-bundle encapsulation by
indicating that one or more bundles are being transmitted as the
payload of a bundle. This extension block is expected to be of
general utility in DTN. It may be used, for example, to encapsulate
a multicast bundle inside of a unicast bundle, or to encapsulate a
bundle with one type of security protection inside of a bundle with a
different type of security protection. This document defines the
format and processing of this new Bundle-in-Bundle Encapsulation
Block and the contents of the Bundle Payload Block accompanying it.
"Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington,
15-Sep-08, <draft-irtf-dtnrg-bundle-previous-hop-block-04.txt>
This document defines an extension block that may be used with the
Bundle Protocol [2] within the context of a Delay-Tolerant Network
architecture [4]. This Previous Hop Insertion Block is designed to
be inserted by a forwarding node to provide information to its next-
hop receiving node. This block is always removed from the bundle by
the receiving node so that it's duration within the bundle lasts for
exactly one hop. It provides a general insertion capability to
enable any node that forwards a bundle to insert an arbitrary record
(or records) of information into the bundle. While this block is
defined to provide an arbitrary insertion capability, this
specification also defines two specific, mandatory, information
record formats for the information that may be carried in the
Previous Hop Insertion block. Using these mandatory information
record formats, an insertion block may be used to indicate the
inserting/forwarding node's endpoint ID (EID), which may be required
in some circumstances to support certain routing protocols (e.g.,
flood routing). This document defines the format and processing of
this Previous Hop Insertion Block.
"Automatic Telephone Configuration Protocol", Bernd Buxmann, Ralf Hintner,
16-Aug-06, <draft-buxmann-atcp-00.txt>
This document is about the Automatic Telephone Configuration
Protocol (ATCP). ATCP provides a framework for passing configuration
information to SIP-telephones in a Voice over IP-network and to
register users in the network. ATCP needs DHCP for configuring the
telephones with TCP/IP-networkparameters (e.g. IP-address).
"SPEERMINT Security Threats and Suggested Countermeasures", Saverio
Niccolini, Eric Chen, Jan Seedorf, Hendrik Scholz, 31-Oct-08,
<draft-niccolini-speermint-voipthreats-05.txt>
This memo presents the different security threats related to
SPEERMINT classifying them into threats to the Location Function, to
the Signaling Function and to the Media Function. The different
instances of the threats are briefly introduced inside the
classification. Finally the existing security solutions in SIP and
RTP/RTCP are presented to describe the countermeasures currently
available for such threats. The objective of this document is to
identify and enumerate the SPEERMINT-specific threat vectors in order
to specify security-related requirements. Once the requirements are
identified, methods and solutions how to achieve such requirements
can be selected.
"LDAP Subtree Data Source URI Attribute", Mark Wahl, 12-Dec-06,
<draft-wahl-ldap-subtree-source-01.txt>
This document defines an attribute that enables administrative
clients using the Lightweight Directory Access Protocol (LDAP) to
determine the source of directory entries.
"Dynamic Feature Extensions to the Presence Information Data Format Location
Object (PIDF-LO)", Singh Vishal, Henning Schulzrinne, Hannes Tschofenig,
30-Oct-08, <draft-singh-geopriv-pidf-lo-dynamic-04.txt>
The Geopriv Location Object introduced by the Presence Information
Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic
XML format for carrying geographical information of a presentity.
The PIDF-LO specification made a subset of the functionality offered
by the Geography Markup Language (GML) standard 3.0 mandatory to
implement. This document defines child elements to the <location-
info> element specified in RFC 4119 to carry temporal feature
elements useful for tracking moving objects. It defines five
elements, namely speed, bearing, acceleration elevation and
directionOfObject.
"Transporting User to User Call Control Information in SIP for ISDN
Interworking", Alan Johnston, Joanne McMillen, 31-Oct-08,
<draft-johnston-sipping-cc-uui-05.txt>
Several approaches to transporting the ITU-T Q.931 User to User
Information Element (UU IE) data in SIP have been proposed. As
networks move to SIP it is important that applications requiring this
data can continue to function in SIP networks as well as the ability
to interwork the information to/from ISDN for end-to-end
transparency. This extension will also be used for native SIP
endpoints implementing similar services and interworking with ISDN
services. This document discusses requirements and approaches and
recommends a new header field User-to-User be standardized. Example
use cases include an exchange between two User Agents, retargeting by
a proxy, and redirection. An example application is in an Automatic
Call Distributor (ACD) in a contact center.
"IPv6 Dynamic Flow Label Switching (FLS)", Martin Beckman, 22-Mar-07,
<draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03.txt>
This document seeks to establish a standard for the utilization of the
Class of Service Field and the us of the Flow Label Field within the IPv6
Header and establish a methodology of switching packets through routers
using the first 32-bits of the IPv6 header using Flow Label Switching on
packets rather than full routing of packets. Within the first 32-bits
of an IPv6 header exists the requisite information to allow for the
immediate “switching” on an ingress packet of a router, allowing for
“Label Switching” of a native IPv6 packet. This allows the establishment
of VPN circuits in a dynamic manner across transit networks. The
establishment of “Flows” based upon the 20-bit “Flow Label” value can be
done dynamically with minimal effort and configuration of the end-point
routers of the flow. The flows can be managed or open, encrypted or in the
clear, and will allow for greater scalability, security, and agility in
the management and operation of networks.
"IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)",
Martin Beckman, 9-Mar-07,
<draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01.txt>
This document outlines a methodology for IPv6 Header Compression via mapping
the source and destination addresses into a flow label value per address
pair sessions with a specific traffic class field value to identify the
packet as “address-less” compressed header. The resultant headers, sans
addresses shrink from 320 bits to 64 bits. This mapping is locally specific
to the router port and the connecting hosts/router ports. Specifically
written for use on low bandwidth links (less than T1 or 1.544Mbps), IPv6
AMP’s applicability goes to integration of cellular/WiFi appliances and will
be critical for tactical uses for military and first responder applications.
"Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy,
30-Oct-08, <draft-irtf-iccrg-cc-rfcs-07.txt>
This document is an informational snapshot produced by the IRTF's
Internet Congestion Control Research Group (ICCRG). It provides a
survey of congestion control topics described by documents in the RFC
series. This does not modify or update the specifications or status
of the RFC documents that are discussed. It may be used as a
reference or starting point for the future work of the research
group, especially in noting gaps or open issues in the current IETF
standards.
"Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer",
Douglas Stebila, 17-Nov-08, <draft-green-secsh-ecc-04.txt>
This document describes algorithms based on Elliptic Curve
Cryptography (ECC) for use within the Secure Shell (SSH) transport
protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman
(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for
use in the SSH Transport Layer protocol.
"DAI Parameter for the "tel" URI", James Yu, David Hancock, Flemming
Andreasen, 12-Jun-08, <draft-yu-tel-dai-05.txt>
This document defines a "dai" parameter for the "tel" Uniform
Resource Identifier (URI) to support the Dial Around Indicator (DAI).
The "dai" parameter is associated with the "cic" parameter, defined
in [RFC4694], and indicates how the carrier identified in the "cic"
parameter was selected. This document also expands the use of the
"cic" parameter to support pre-subscribed and dialed long-distance
carrier requirements.
"Design Considerations for Protocol Extensions", Brian Carpenter, Bernard
Aboba, 27-Oct-08, <draft-carpenter-extension-recs-04.txt>
This document discusses issues related to the extensibility of
Internet protocols, with a focus on the architectural design
considerations involved. Concrete case study examples are included.
It is intended to assist designers of both base protocols and
extensions.
"Atom Bidirectional Attribute", James Snell, 11-Apr-08,
<draft-snell-atompub-bidi-06.txt>
This document adds a new attribute to the Atom Syndication Format
used to indicate the base directionality of directionally-neutral
characters.
"Requirements for vertical handover of multimedia sessions using SIP",
Saverio Niccolini, Stefano Salsano, Haruki Izumikawa, Ross Lillie, Luca
Veltri, Yoji Kishi, 3-Nov-08, <draft-niccolini-sipping-siphandover-05.txt>
A vertical handover occurs in heterogeneous networks when a session
media is moved among different access network technologies within the
same device. This document analyses the issue of handling the
vertical handover using the Session Initiation Protocol (SIP) [1].
"GSSAPI authentication for HTTP", Leif Johansson, 2-Nov-08,
<draft-johansson-http-gss-04.txt>
This document specifies a template extension to the HTTP Negotiate
authentication mechanism defined in RFC4559 which supports mutual
authentication, fast session-based re-authentication and channel
bindings. An IANA registry for such GSS-API HTTP authentication
mechanisms is defined.
"Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre,
16-Oct-08, <draft-saintandre-rfc3920bis-08.txt>
This document defines the core features of the Extensible Messaging
and Presence Protocol (XMPP), a technology for streaming Extensible
Markup Language (XML) elements for the purpose of exchanging
structured information in close to real time between any two or more
network-aware entities. XMPP provides a generalized, extensible
framework for incrementally exchanging XML data, upon which a variety
of applications can be built. The framework includes methods for
stream setup and teardown, channel encryption, authentication of a
client to a server and of one server to another server, and
primitives for push-style messages, publication of network
availability information ("presence"), and request-response
interactions. This document also specifies the format for XMPP
addresses, which are fully internationalizable.
This document obsoletes RFC 3920.
"Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and
Presence", Peter Saint-Andre, 24-Oct-08, <draft-saintandre-rfc3921bis-07.txt>
This document defines extensions to core features of the Extensible
Messaging and Presence Protocol (XMPP) that provide basic instant
messaging (IM) and presence functionality in conformance with RFC
2779.
This document obsoletes RFC 3921.
"A Uniform Resource Name Namespace For The GSM Association (GSMA) and the
International Mobile station Equipment Identity(IMEI)", Andrew Allen, David
McDonald, Michael Montemurro, 1-Oct-08,
<draft-montemurro-gsma-imei-urn-02.txt>
This specification defines a Uniform Resource Name namespace for the
GSMA and sub namespaces for the IMEI (International Mobile station
Equipment Identity), and for the IMEISV (International Mobile station
Equipment Identity and Software Version number). The IMEI is 15
decimal digits long and the IMEISV is 16 decimal digits long and are
both encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV
were introduced as part of the specification for Global System for Mobile
(GSM) and are also now incorporated by the 3rd Generation Partnership Project
(3GPP) as part of the 3GPP specification for GSM, and the Universal Mobile
Telecommunications System (UMTS). The IMEI and IMEISV are used to uniquely
identify Mobile Equipment within these systems and are managed by the GSMA
(GSM Association).
"Sharing Transaction Fraud Data", Sharon Boeyen, Michael Grandcolas,
Siddharth Bajaj, David M'Raihi, 25-Aug-08, <draft-mraihi-inch-thraud-07.txt>
This document describes a document format for exchanging
transaction fraud (Thraud) information. It extends the Incident
Handling Working Group (INCH WG) Incident Object Description
Exchange Format (IODEF) incident reporting document format.
"Simple SIP Usage Scenario for Applications in the Endpoints", Henry
Sinnreich, Alan Johnston, Eunsoo Shim, 21-Nov-08,
<draft-sinnreich-sip-tools-04.txt>
For Internet-centric usage, the number of SIP related standards for
presence, IM and audio/video communications can be drastically
reduced by using only the rendezvous and session initiation
capabilities of SIP. The simplification is based on avoiding
emulating telephony and its model of the intelligent network. Simple
SIP by contrast relies on powerful computing endpoints. Simple SIP
desktop applications for example can be combined with rich Internet
applications (RIA). However, significant telephony features may also
be implemented in the endpoints.
This approach for SIP reduces the number of SIP standards to comply
with, currently from roughly 100 and still growing, to about 10.
References for NAT traversal and for security are also provided.
"Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Indra
Widjaja, Henning Schulzrinne, 13-Jul-08, <draft-hilt-sipping-overload-05.txt>
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines an overload control mechanism for SIP.
"IANA Registering a SIP Resource Priority Header Namespace for Local
Emergency Communications", James Polk, 14-Jul-08,
<draft-polk-ecrit-local-emergency-rph-namespace-03.txt>
This document creates and IANA registers the new Session Initiation
Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
local emergency usage to a public safety answering point (PSAP),
between PSAPs, and between a PSAP and first responders and their
organizations.
"Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and
Other Crimeware", Patrick Cain, David Jevans, 30-Jul-08,
<draft-cain-post-inch-phishingextns-05.txt>
This document extends the Incident Object Description Exchange Format
(IODEF) to support the reporting of phishing, fraud, other types of
electronic crime, and widespread spam incidents. These extensions
are flexible enough to support information gleaned from activities
throughout the entire electronic fraud cycle. Both simple reporting
and complete forensic reports are possible, as is consolidated
reporting of multiple phishing incidents.
The extensions defined in this document are used to generate two
different types of reports: a fraud and phishing report and a wide-
spread spam report. Although similar in structure, each report has
different required objects and intents.RFC 2129 Keywords
"HELD Identity Extensions", Martin Thomson, Hannes Tschofenig, Richard
Barnes, James Winterbottom, 3-Nov-08,
<draft-winterbottom-geopriv-held-identity-extensions-07.txt>
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 arriving message as a pointer to the location
determination process. This is sufficient in environments where an
Target's location can be determined based on its IP address.
Two additional use cases are addresses by this document. In the
first, the source IP address in the request is not the only
identifier for the Target. In the second, an entity other than the
Target requests the Target's location.
This document extends the HELD protocol to allow the location request
message to carry additional identifiers assisting the location
determination process. It defines a set of URIs for Target
identifiers and an XML containment schema. This extension is used in
conjunction with HELD to provide Target identification, and set of
criteria of when to use this extensions are provided. Examples and
usage in HELD message syntax are also shown.
"A Process for Handling Essential Corrections to the Session Initiation
Protocol (SIP)", Keith Drage, 2-Jul-08,
<draft-drage-sip-essential-correction-03.txt>
The Session Initial Protocol (SIP) defined in RFC 3261 and a large
number of extensions forms a considerable body of work, which through
sheer size has a number of errors that require correction. This
document explains the process for managing essential corrections to
SIP.
"The SIEVE mail filtering language - extension for accessing mailbox
metadata", Alexey Melnikov, 20-Nov-08,
<draft-melnikov-sieve-imapext-metadata-05.txt>
This memo defines an extension to the SIEVE mail filtering language
(RFC 5228) for accessing mailbox and server annotations (variables).
"HTTP State Management Mechanism v2", Yngve Pettersen, 3-Nov-08,
<draft-pettersen-cookie-v2-03.txt>
This document specifies a way to create a stateful session with
Hypertext Transfer Protocol (HTTP) requests and responses. It
describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents. The method described here differs from both Netscape's
Cookie proposal [Netscape], and [RFC2965], but it can, provided some
requirements are met, interoperate with HTTP/1.1 user agents that use
Netscape's method. (See the HISTORICAL section.)
This document defines new rules for how cookies can be shared between
servers within a domain. These new rules are intended to address
security and privacy concerns that are difficult to counter for
clients implementing Netscape's proposed rules or the rules specified
by RFC 2965.
This document reflects implementation experience with RFC 2965 and
obsoletes it.
"An uniform format for IPv6 extension headers", Suresh Krishnan, James
Woodyatt, Erik Kline, James Hoagland, 14-Oct-08,
<draft-krishnan-ipv6-exthdr-06.txt>
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.
"The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions", Arnt Gulbrandsen,
Intellectual Property, 21-Oct-08, <draft-gulbrandsen-imap-inthread-03.txt>
The SEARCH=INTHREAD extension extends the IMAP SEARCH command to
operate on threads as well as individual messages. Other commands
which search are implicitly extended.
The THREAD=REFS extension provides a threading algorithm using
(almost) only the References header field for use with the IMAP
THREAD command.
"Diameter Congestion Signaling", Tolga Asveren, Victor Fajardo, 15-Jul-08,
<draft-asveren-dime-cong-03.txt>
Diameter base protocol defines the network layer functionality to be
used by applications. This document adds hop-to-hop congestion
notification mechanism to that functionality.
"Credential Protection Ciphersuites for Transport Layer Security (TLS)",
Ibrahim Hajjeh, 6-Oct-08, <draft-hajjeh-tls-identity-protection-07.txt>
This document defines a set of cipher suites to add client credential
protection to the Transport Layer Security (TLS) protocol. By
negotiating one of those ciphersuites, the TLS clients will be able
to determine for themselves when, how, to what extent and for what
purpose information about them is communicated to others. The
ciphersuites defined in this document can be used only when public
key certificates are used in the client authentication process.
"IODEF/RID over SOAP", Brian Trammell, Kathleen Moriarty, 25-Feb-08,
<draft-moriarty-post-inch-rid-soap-05.txt>
Documents intended to be shared among multiple constituencies must
share a common format and transport mechanism. The Incident Object
Description Exchange Format (IODEF) defines a common XML format for
document exchange. This draft outlines the SOAP wrapper for all
IODEF documents and extensions to facilitate an interoperable and
secure communication of documents. The SOAP wrapper allows for
flexibility in the selection of a transport protocol. The
transport protocols will be provided through existing standards and
SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP.
"Calendar Availability", Cyrus Daboo, Bernard Desruisseaux, 3-Nov-08,
<draft-daboo-calendar-availability-01.txt>
This document specifies a new iCalendar calendar component that
allows the publication of available and unavailable time periods
associated with a calendar user. This component can be used in
standard iCalendar free-busy lookups, including iTIP free-busy
requests, to generate repeating blocks of available or busy time with
exceptions as needed.
This document also defines extensions to CalDAV calendar-access and
calendar-auto-schedule which specify how this new calendar component
should be used when doing free busy time evaluation in CalDAV.Editorial Note
(To be removed by RFC Editor before publication)
Discussion of this specification is taking place on the mailing list
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav.
"Real-time Inter-network Defense", Kathleen Moriarty, 21-Oct-08,
<draft-moriarty-post-inch-rid-07.txt>
Network security incidents, such as system compromises, worms,
viruses, phishing incidents, and denial of service, typically
result in the loss of service, data, and resources both human and
system. Network providers and Computer Security Incident Response
Teams need to be equipped and ready to assist in communicating and
tracing security incidents with tools and procedures in place
before the occurrence of an attack. Real-time Inter-network
Defense outlines a proactive inter-network communication method to
facilitate sharing incident handling data while integrating
existing detection, tracing, source identification, and mitigation
mechanisms across for a complete incident handling solution.
Combining these capabilities in a communication system provides a
way to achieve higher security levels on networks. Policy
guidelines for handling incidents are recommended and can be agreed
upon by a consortium using the security recommendations and
considerations.
"Dynamic Host Configuration Protocol Option for Geodetic Location
Information", Martin Thomson, James Winterbottom, 3-Jul-08,
<draft-thomson-geopriv-3825bis-02.txt>
This document specifies a Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for the coordinate-based geographic location of
the client. The Location Configuration Information (LCI) includes
latitude, longitude, and altitude, with an indication of uncertainty
for each. Separate parameters indicate the reference datum for each
of these values.
"Suite B Profile for Transport Layer Security (TLS)", Margaret Salter, Eric
Rescorla, Russ Housley, 17-Nov-08, <draft-rescorla-tls-suiteb-11.txt>
The United States Government has published guidelines for "NSA Suite
B Cryptography", which defines cryptographic algorithm policy for
national security applications. This document defines a profile of
TLS version 1.2 which is fully conformant with Suite B. This document
also defines a transitional profile for use with TLS version 1.0 and
TLS version 1.1 employ Suite B algorithms to the greatest extent
possible.
"Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, 27-Oct-08,
<draft-mun-mipshop-fhmacro-03.txt>
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.
"FTP EXTENSION ALLOWING IP FORWARDING (NATs)", Martin Rosenau, 18-Sep-08,
<draft-rosenau-ftp-single-port-05.txt>
The FTP protocol [1] needs two connections. A control and a data
connection. Using networks with "port forwarding" (eg. SSH, DSL
routers, VPN etc.) there is often only the possibility for the
server to listen on only one TCP port. In such networks the
traditional FTP protocol cannot be used.
This memo describes an extension to the FTP protocol that allows the
use of FTP using only one TCP port number for both control
connections and passive-mode data connections.
The extension can also be used to use the FTP protocol over network
protocols that do not have a "port" concept (such as the NetBIOS
protocol).
"A Conference List Information Event Package for the Session Initiation
Protocol (SIP)", Michael Fortinsky, Ilan Ravid, Oded Koren, 3-Jul-08,
<draft-koren-sipping-conference-list-event-03.txt>
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications related to conference
lists.
A new conference list event package is specified. This event package
allows a user to subscribe to a single event (the conference-list) and receive
notifications that contain the list of conferences to which the user belongs
and the status of each conference. The notifications sent from the conference
server can contain either the entire list of the user's conferences or a
partial list with the updates since the previous notification.
"IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das,
2-Nov-08, <draft-ohba-802dot21-basic-schema-05.txt>
This document describes an RDF (Resource Description Framework)
schema defined in IEEE 802.21 as the basic schema for Media-
Independent Information Service. This document serves as the
Specification required by the IANA to maintain a global registry for
storing the RDF schema.
"Distributed DNS Implementation in IpV6", Lican Huang, 23-Jun-08,
<draft-licanhuang-dnsop-distributeddns-04.txt>
This file is a proposal for P2P based Domain Name query stratagy in
IpV6. The DNS servers construct n-tuple overlay virtual hierarchical
overlay network. With cached addresses of DNS servers, the overload
of traffic in tree structure can be avoided. This strategy may use
for Domain Name query and reverse Domain Name query in IpV6 for a
large number of domain names.
"Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, David
Oran, Dave Meyer, Scott Brim, 10-Oct-08, <draft-farinacci-lisp-09.txt>
This draft describes a simple, incremental, network-based protocol to
implement separation of Internet addresses into Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). This mechanism requires no
changes to host stacks and no major changes to existing database
infrastructures. The proposed protocol can be implemented in a
relatively small number of routers.
This proposal was stimulated by the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
place in October 2006.
"Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and Multihomed
Nodes", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo,
Basavaraj Patil, Hannes Tschofenig, 25-Jun-08,
<draft-haddad-alien-threat-model-02.txt>
This memo describes privacy threats related to the MAC and IP layers
identifiers in a mobile and multi-homed environment.
"Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem
Statement", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo,
Basavaraj Patil, 25-Jun-08, <draft-haddad-alien-problem-statement-02.txt>
This memo describes the anonymous layers identifiers in mobility and
multi-homing problem statement.
"Progress notifications for HTTP", Andrien de Croy, 23-Jul-08,
<draft-decroy-http-progress-04.txt>
This document specifies an extension to HTTP to allow the sending of
progress messages to user-agents during lengthy processing which
could otherwise cause users or user-agents to abandon requests.
"Requirements for the XCON-DCON Synchronization Protocol", Simon Romano,
Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono,
20-Jun-08, <draft-romano-dcon-xdsp-reqs-03.txt>
The Distributed Conferencing (DCON) framework provides the means to
distribute Centralized Conference (XCON) information by appropriately
orchestrating a number of centralized focus entities (clouds). The
mechanism we propose to make each XCON cloud communicate with its
related DCON peer is based on the use of some kind of XCON-DCON
Synchronization Protocol (XDSP). This document gives the
requirements for XDSP.
"Requirements for Distributed Conferencing", Simon Romano, Alessandro
Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-08,
<draft-romano-dcon-requirements-03.txt>
This document examines the requirements for Distributed Conferencing
(DCON). Separate documents will map the requirements to existing
protocol primitives, define new protocol extensions, and introduce
new protocols as needed. Together, these documents will provide a
guideline for building interoperable conferencing applications. The
current works in SIPPING and XCON working groups marginally address
the matter, which is nonetheless considered as out-of-scope. The
requirements listed in this document are in part based on thoughts
derived from the cited working groups activities.
"A Framework for Distributed Conferencing", Simon Romano, Alessandro
Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 20-Jun-08,
<draft-romano-dcon-framework-03.txt>
This document defines the framework for Distributed Conferencing
(DCON). The framework draws inspiration from the work carried out in
the XCON working group, which has defined a complete architecture for
centralized conferencing. DCON is based on the idea that a
distributed conference can be setup by appropriately orchestrating
the operation of a number of XCON focus elements, each in charge of
managing a certain number of participants. Interaction between each
participant and the corresponding conference focus is based on the
standard XCON framework, whereas inter-focus interaction is defined
in this document.
"PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, Frank Suraci,
Bob Schaefer, 31-Oct-08, <draft-goldman-pcn-pstn-scope-04.txt>
The IETF PCN Working Group has continued its work investigating pre-
congestion and admission control mechanisms. This work has
progressed under the current charter, but has not yet considered
related legacy PSTN interactions or the need for ubiquitous
connectivity between users on dissimilar networks. The PCN charter
could be improved by a strong positive statement to the effect
committing to future work addressing legacy networks.
In that light, please consider the questions below which include
differential PCN treatment based on traffic types, security, and PSTN
interoperability concerns. It seems helpful to have a touchstone of
some concerns relative to the PSTN network and IP network Gateway in
order to confirm that they will be addressed in future work. This
attempt is motivated by a desire to avoid the accidental omission of
a topic that may be hard to "retrofit" in later.
"Service Selection for Mobile IPv4", Jouni Korhonen, Ulf Nilsson, 3-Nov-08,
<draft-korhonen-mip4-service-05.txt>
In some Mobile IPv4 deployments identifying the mobile node or the
mobility service subscriber is not enough to distinguish between
multiple services possibly provisioned to the said mobile node and
its mobility service subscription. A capability to specify different
services in addition to the mobile node identity can be leveraged to
provide flexibility for mobility service providers to provide
multiple services within a single mobility service subscription.
This document describes a Service Selection Extension for Mobile IPv4
that is intended to assist home agents to make specific service
selections for the mobility service subscription during the
registration procedure.
"Common Architecture Label IPv6 Security Option (CALIPSO)", Michael StJohns,
25-Aug-08, <draft-stjohns-sipso-05.txt>
This document describes an optional method for encoding
explicit packet Sensitivity Labels on IPv6 packets. It is
intended for use only within Multi-Level secure (MLS) networking
environments that are both trusted and trustworthy.
"Secure Media Recording and Transcoding with the Session Initiation
Protocol", Dan Wing, Francois Audet, Steffen Fries, Hannes Tschofenig, Alan
Johnston, 31-Oct-08, <draft-wing-sipping-srtp-key-04.txt>
Call recording is an important feature in enterprise telephony
applications. Some industries such as financial traders have
requirements to record all calls in which customers give trading
orders. This poses a particular problem for Secure RTP systems as
many SRTP key exchange mechanisms do not disclose the SRTP session
keys to intermediate SIP proxies. As a result, these key exchange
mechanisms cannot be used in environments where call recording is
needed.
This document specifies a secure mechanism for a cooperating endpoint
to disclose its SRTP master keys to an authorized party to allow
secure call recording.
"DHCP Vendor-specific Message", Bernie Volz, 7-Jul-08,
<draft-volz-dhc-dhcpv6-vendor-message-01.txt>
This document requests a vendor-specific DHCPv6 message assignment.
This message can be used for vendor specific and experimental
purposes.
"Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Larry
Zhu, Jeffrey Altman, Nicolas Williams, 3-Nov-08, <draft-zhu-pku2u-09.txt>
This document defines a Generic Security Services Application Program
Interface (GSS-API) mechanism based on Public Key Infrastructure
(PKI) - PKU2U. This mechanism is based on Kerberos V messages and the
Kerberos V GSS-API mechanism, but without requiring a Kerberos Key
Distribution Center (KDC).
"The stale-if-error HTTP Cache-Control Extension", Mark Nottingham, 8-May-08,
<draft-nottingham-http-stale-if-error-01.txt>
The stale-if-error HTTP Cache-Control extension improves availability
of some kinds of cached content by allowing servers and clients to
instruct caches to use stale responses when certain error conditions
are encountered.
"The stale-while-revalidate HTTP Cache-Control Extension", Mark Nottingham,
8-May-08, <draft-nottingham-http-stale-while-revalidate-01.txt>
The stale-while-revalidate HTTP response Cache-Control extension
allows servers to instruct caches to serve stale responses while
validating them, to avoid latency in some situations.
"Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)",
Dale Worley, 6-Jul-08, <draft-worley-redundancy-response-03.txt>
An increasing number of SIP architectures implement multiple path
routing (MPR), which is the providing of more than one path for a
call to reach a destination user agent (UA). To implement MPR well,
the proxy which forks a request onto the redundant paths needs to be
able to determine if a fork that failed reached the destination UA
and was rejected by the UA (and so an alternate path should not be
tried), or if the fork failed before reaching the UA (and so an
alternate path should be attempted). This document is to begin a
discussion of strategies for making this determination.
"A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom,
3-Jul-08, <draft-thomson-geopriv-held-beep-02.txt>
A BEEP binding is described for HELD. This binding is more suitable
than the basic HTTP binding in scenarios where multiple messages are
sent between the same two parties.
"Digital Signature Methods for Location Dependability", Martin Thomson, James
Winterbottom, 3-Jul-08, <draft-thomson-geopriv-location-dependability-02.txt>
The dependability of location information is closely related to the
degree of trust placed in the source of that information. This
document describes techniques that can be used to mitigate the impact
of falsifying location information. The application of digital
signatures is described, relating these methods to the attacks that
they address.
"Vouch By Reference", Paul Hoffman, John Levine, Arvel Hathcock, 9-Oct-08,
<draft-hoffman-dac-vbr-04.txt>
This document describes the Vouch By Reference (VBR) protocol. VBR
is a protocol for adding third-party certification to email. It
permits independent third parties to certify the owner of a domain
name that is associated with received mail.
"FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent
Roca, Brian Adamson, 2-Oct-08, <draft-roca-rmt-newfcast-03.txt>
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.
"Media Gateway Control Protocol Voiceband Data Package and General Purpose
Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar,
3-Jul-08, <draft-stone-mgcp-vbd-03.txt>
This document defines Media Gateway Control Protocol (MGCP) packages
that enable a Call Agent to authorize and monitor the transition of a
connection to and from voiceband data (VBD) with or without
redundancy and FEC (forward error correction). Although the focus is
on VBD, the General-Purpose Media Descriptor Parameter package can be
used to authorize other modes of operation, not relevant to VBD, for
a particular codec. In addition to the definition of these new
packages, this document describes the use of the Media Format
Parameter package and Fax package with VBD, redundancy and FEC.
"SIP URI Service Discovery using DNS-SD", Jae Woo Lee, Henning Schulzrinne,
Wolfgang Kellerer, Zoran Despotovic, 12-Jul-08,
<draft-lee-sip-dns-sd-uri-03.txt>
This document describes how to use the DNS-based Service Discovery
(DNS-SD), better known as Apple Bonjour, for advertising Session
Initiation Protocol (SIP) URIs in local area networks. Using this
mechanism, a SIP user agent (UA) can communicate with another UA even
when no SIP registrar is available, as in a wireless ad-hoc network
for example.
"IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, Mats
Naslund, Pekka Nikander, 13-Jul-08,
<draft-haddad-mipshop-tunneling-optimization-01.txt>
This memo introduces a simple tunneling optimization mechanism, which
removes the need for inserting an additional header in the IP packet.
The main goals are to minimize the packet size, provide a simpler
protocol design and a better efficiency.
"MANET Position and Mobility Signaling: Problem Statement", Jerome Haerri,
Christian Bonnet, Fethi Filali, 14-Jul-08,
<draft-haerri-manet-position-problem-statement-01.txt>
This document states the problem of optimizing the structures created
by mobile network or MANET protocols to a mobile network topology.
It also justifies the use and the transmission of position
information to mitigate this problem.
"VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi,
14-Jul-08, <draft-sajassi-l2vpn-vpls-pbb-interop-03.txt>
The scalability of H-VPLS with Ethernet access network can be
improved by incorporating Provider Backbone Bridge (PBB)
functionality in VPLS access. PBB is in the process of being
standardized as IEEE 802.1ah, which is an amendment to 802.1Q to
improve the scalability of MAC addresses and service instances in
Provider Ethernet networks. This document describes how IEEE 802.1ah
functionality can be used in the H-VPLS access network to attain
better scalability in terms of number of customer MAC addresses and
number of service instances that can be supported. This document
also describes the scenarios and the mechanisms for incorporating
PBB functionality within H-VPLS with existing IEEE 802.1ad (aka
QinQ) Ethernet access and interoperability among them.
"MANET Position and Mobility Signaling Format", Jerome Haerri, Christian
Bonnet, Fethi Filali, 14-Jul-08,
<draft-haerri-manet-position-signaling-01.txt>
This document describes an extension to the node metric TLV defined
in the MetricTLV document to specify a configurable structure to
exchange position and mobility information for MANET protocols.
"Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG
Messages", Vladislav Marinov, 1-Oct-08, <draft-marinov-syslog-snmp-02.txt>
This memo defines a mapping from Simple Network Management Protocol
(SNMP) notifications to SYSLOG notifications.
"Media Description for IKE in the Session Description Protocol (SDP)", Makoto
Saito, Dan Wing, 27-Jul-08, <draft-saito-mmusic-sdp-ike-03.txt>
This document extends the protocol identifier of SDP so that it could
negotiate the use of IKE for media session in SDP offer/answer model.
And it also specifies the method to boot up IKE and generate IPsec SA
using self-signed certificate under the mechanism of comedia-tls.
This document extends RFC 4572. In addition, it defines a new
attribute "udp-setup", which is similar to "setup" attribute defined
in RFC 4145, to enable endpoints to negotiate their roles in the IKE
session. Considering the case that pre-shared keys can be used for
authentication in IKE, a new attribute "psk-fingerprint" is also
defined.
"The Multiple Appearance Feature using the Session Initiation Protocol
(SIP)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul
Pepper, Anil Kumar, 13-Jul-08, <draft-johnston-bliss-mla-req-02.txt>
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as Multiple Appearances (MA) since
SIP does not have lines. This feature is commonly offered in the IP
Centrex services and IP-PBX offerings and is likely to be implemented
on SIP IP telephones and SIP feature servers used in a business
environment. This document lists requirements and compares
implementation options for this feature. Extensions to the SIP
dialog event package are proposed.
"Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim,
Dominik Kaspar, Carles Gomez, Carsten Bormann, 17-Nov-08,
<draft-dokaspar-6lowpan-routreq-08.txt>
This document provides the problem statement for 6LoWPAN routing. It
also defines the requirements for 6LoWPAN routing considering IEEE
802.15.4 specificities and the low-power characteristics of the
network and its devices.
"PCE communication protocol(PCEP) Management Information Base", Emile
Stephan, Kiran Koushik, 3-Nov-08, <draft-kkoushik-pce-pcep-mib-02.txt>
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.
"A context mechanism for controlling caching of HTTP responses", Yngve
Pettersen, 3-Nov-08, <draft-pettersen-cache-context-03.txt>
A common problem for sensitive web services is informing the client,
in a reliable fashion, when a password protected resource is no
longer valid because the user is logged out of the service. This is,
in particular, considered a potential security problem by some
sensitive services, such as online banking, when the user navigates
the client's history list, which is supposed to display the resource
as it was when it was loaded, not as it is at some later point in
time.
This document presents a method for collecting such sensitive
resources into a group, called a "Cache Context", which permits the
server to invalidate all the resources belonging in the group either
by direct action, or according to some expiration policy. The
context can be configured to invalidate not just the resources, but
also specific cookies, HTTP authentication credentials and HTTP over
TLS session information.
"Security requirements in Peer-to-Peer Session Initiation Protocol (P2PSIP)",
Song Yongchao, Marcin Matuszewski, Dan York, 3-Nov-08,
<draft-matuszewski-p2psip-security-requirements-04.txt>
This document outlines the security requirements for a Peer-to-Peer
Session Initiation Protocol (P2PSIP) overlay network. It compares
security difference between client/server (C/S) and P2P
implementations of SIP, partitions the P2PSIP architecture into
layers and analyzes the security issues in each layer and the
security relationship among the layers. This draft also describes
the different security requirements related to different application
scenarios as well as a minimal set of security requirements valid for
all applications. It also discusses open issues related to certain
security threats for the P2PSIP architecture and its components.
"Network In Node Advertisement", Pascal Thubert, Carlos Bernardos, 12-Sep-08,
<draft-thubert-nina-03.txt>
The Internet is evolving to become a more ubiquitous network, driven
by the low prices of wireless routers and access points and by the
users' requirements of connectivity anytime and anywhere. For that
reason, a cloud of nodes connected by wireless technology is being
created at the edge of the Internet. We refer to this cloud as a
Fringe Stub (FS). It is expected that networking in the FS will be
highly unmanaged and ad-hoc, but at the same time will need to offer
excellent service availability. The NEMO Basic Support protocol
could be used to provide global reachability for a mobile access
network within the FS and the Tree-Discovery mechanism could be used
to avoid the formation of loops in this highly unmanaged structure.
Since Internet connectivity in mobile scenarios can be costly,
limited or unavailable, there is a need to enable local routing
between the Mobile Routers within a portion of the FS. This form of
local routing is useful for Route Optimization (RO) between Mobile
Routers that are communicating directly in a portion of the FS.
Network In Node Advertisement (NINA) is the second of a 2-passes
routing protocol; a first pass, Tree Discovery, builds a loop-less
structure -- a tree --, and the second pass, NINA, exposes the Mobile
Network Prefixes (MNPs) up the tree. The protocol operates as a
multi-hop extension of Neighbor Discovery (ND), to populate TD-based
trees with prefixes, and establish routes towards the MNPs down the
tree, from the root-MR towards the MR that owns the prefix, whereas
the default route is oriented towards the root-MR.
The NINA protocol introduces a new option in the ND Neighbor
Advertisement (NA), the Network In Node Option (NINO). An NA with
NINO(s) is called a NINA (Network In Node Advertisement). NINA is
designed for a hierarchical model, and by using this NA based
approach it abstracts the embedded network of a Mobile Router as a
host to the upper level of network abstraction. With NINA, a Mobile
Router presents its sub-tree to its parent as an embedded network and
hides the inner topology and movements.
"A Document Format for Expressing Authorization Policies to tackle Spam and
Unwanted Communication for Internet Telephony", Hannes Tschofenig, Dan Wing,
Henning Schulzrinne, Thomas Froment, Geoffrey Dawirs, 12-Jul-08,
<draft-tschofenig-sipping-spit-policy-03.txt>
SPAM, defined as sending unsolicited messages to someone in bulk,
might be a problem on SIP open-wide deployed networks. The
responsibility for filtering or blocking calls can belong to
different elements in the call flow and may depend on various
factors. This document defines an authorization based policy
language that allows end users to upload anti-SPIT policies to
intermediaries, such as SIP proxies. These policies mitigate
unwanted SIP communications. It extends the Common Policy
authorization framework with additional conditions and actions. The
new conditions match a particular Session Initiation Protocol (SIP)
communication pattern based on a number of attributes. The range of
attributes includes information provided, for example, by SIP itself,
by the SIP identity mechanism, by information carried within SAML
assertions.
"LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire", Frederic
JOUNAY, 31-Oct-08, <draft-jounay-pwe3-leaf-initiated-p2mp-pw-01.txt>
This document provides a solution to extend LDP signaling in order to
allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP
PW). Such an extension of existing point to point Pseudowire is made
necessary by new applications. The document deals with the leaf-
initiated P2MP PW setup and maintenance. The processing for setting
up a P2MP MS-PW is built on the processing for setting up a P2MP LSP
with LDP.
"LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire",
Frederic JOUNAY, 31-Oct-08,
<draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01.txt>
This document provides a solution to extend Label Distribution
Protocol (LDP) signaling in order to allow set up and maintenance of
Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of
existing point to point Pseudowire is made necessary by new
applications. The document deals with the source-initiated P2MP PW
setup and maintenance.
"Considerations about Multicast for BGP/MPLS VPN Standardization", Thomas
Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil
Bitar, 11-Jul-08, <draft-morin-l3vpn-mvpn-considerations-03.txt>
The current proposal for multicast in BGP/MPLS includes multiple
alternative mechanisms for some of the required building blocks of
the solution. The aim of this document is to leverage previously
documented requirements to identify the key elements and help move
forward solution design, toward the definition of a standard having a
well defined set of mandatory procedures. The different proposed
alternative mechanisms are examined in the light of requirements
identified for multicast in L3VPNs, and suggestions are made about
which of these mechanisms standardization should favor. Issues
related to existing deployments of early implementations are also
addressed.
"Implementing Call Park and Retrieve using the Session Initiation Protocol
(SIP)", Michael Procter, 21-Oct-08,
<draft-procter-bliss-call-park-extension-03.txt>
Call Park and Call Retrieve are useful telephony services that are
familiar to many users. Existing implementations using the Session
Initiation Protocol (SIP) show that a variety of approaches can be
taken, with varying degrees of interoperability. This draft
discusses a number of feature variations, and how they may be
implemented using existing techniques. An additional URI parameter
is also described, which enables further common use-cases to be
implemented.
"Authentication Protocol for Mobile IPv6", Alpesh Patel, Kent Leung, Mohamed
Khalil, Haseeb Akhtar, Kuntal Chowdhury, 14-Jul-08,
<draft-ietf-mip6-rfc4285bis-03.txt>
IPsec is specified as the means of securing signaling messages
between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6
signalling 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 Mobile IPv6 signaling messages between a Mobile
Nodes and Home Agents. The alternate method defined here consists of
a Mobile IPv6 specific authentication option that can be added to
Mobile IPv6 signalling messages.
"An Architecture for Human Meetings and Dating websites using other Social
Networking Internet resources.", Varun Srivastava, 29-Aug-07,
<draft-varun-social-networking-02.txt>
This document describes an architecture for online meetings and
dating websites. The proposed architecture can use its own profiles
database as well as the other internet based social networking
database resources. The document proposes a modular design for
online meeting and similar kind of applications on Internet. The
architecture proposes an application specific search without
breaching privacy of the registered members. It also proposes to
utilize member profiles from legacy databases and websites as well as
other implementations of this architecture.
"The Minger Email Address Verification Protocol", Arvel Hathcock, Jonathan
Merkel, 9-Jul-08, <draft-hathcock-minger-05.txt>
This document describes the Minger protocol. Minger is a protocol
which allows a mail handling entity to query a remote service and
ask the question "do you accept mail for this email address?" It
includes security in the form of a hashed shared secret but can also
be used anonymously if desired.
"The DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow,
Stephane Combes, 4-Sep-08, <draft-combes-ipdvb-mib-rcs-04.txt>
his document describes the MIB module for the Digital Video
Broadcasting Return Channel via Satellite system (DVB-RCS). It
defines a set of MIB entities to characterize the behavior and
performance of network layer entities deploying DVB-RCS.
"Extensible Supply-chain Discovery Service Concepts", Michael Young,
29-Aug-08, <draft-young-esds-concepts-04.txt>
This document is intended to seed discussion about the Extensible
Supply-chain Discovery Service (ESDS), an application layer protocol
for the distributed sharing and discovery of notification events
between associated partners within a supply chain. Specified
initially as a web service interface, the protocol defines event
tracking and tracing operations as well as core object management
operations. This document obsoletes "Extensible Supply-chain
Discovery Service Concepts draft-young-esds-concepts-03".
Comments are solicited and should be addressed to the mailing list at
esds@ietf.org and/or the author(s).
"Extensible Supply-chain Discovery Service Commands", Frank Thompson,
29-Aug-08, <draft-thompson-esds-commands-04.txt>
The Extensible Supply-chain Discovery Service (ESDS) is an
application layer protocol for the distributed sharing and discovery
of notification events between associated partners within a supply
chain. This document describes the details of the command interface
of the ESDS. A full outline of all primary and support commands is
included in this document along with examples.
Comments are solicited and should be addressed to the mailing list at
esds@ietf.org and/or the author(s).
"Extensible Supply-chain Discovery Service Schema", Frank Thompson,
29-Aug-08, <draft-thompson-esds-schema-04.txt>
The Extensible Supply-chain Discovery Service (ESDS) is an
application layer protocol for the distributed sharing and discovery
of notification events between associated partners within a supply
chain. This document outlines the schema of the ESDS application
layer protocol. This is the formal syntax of the web service
interface specification in Web Service Description Language (WSDL)
and XML Schema (XSD).
Comments are solicited and should be addressed to the mailing list at
esds@ietf.org and/or the author(s).
"Adding Acknowledgement Congestion Control to TCP", Sally Floyd, Intellectual
Property, 14-Jul-08, <draft-floyd-tcpm-ackcc-04.txt,.pdf>
This document adds an optional congestion control mechanism for
acknowledgement traffic (ACKs) to TCP. The document specifies an
end-to-end acknowledgement congestion control mechanism for TCP that
uses participation from both TCP hosts, the TCP data sender and the
TCP data receiver. The TCP data sender detects lost and ECN-marked
ACK packets, and tells the TCP data receiver the ACK Ratio R to use
to respond to the congestion on the reverse path from the data
receiver to the data sender. The TCP data receiver sends roughly one
ACK packet for every R data packets received. This mechanism is
based on the acknowledgement congestion control in DCCP's CCID 2.
This acknowledgement congestion control mechanism is being proposed
as an experimental mechanism for TCP for evaluation by the network
community.
"The Session Initiation Protocol (SIP) P-Served-User Private-Header
(P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", Hans
Erik van Elburg, 18-Nov-08, <draft-vanelburg-sipping-served-user-08.txt>
This document specifies the SIP P-Served-User P-header. This header
field addresses an issue that was found in the 3rd-Generation
Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an
S-CSCF (Serving Call Session Control Function) and an AS (Application
Server) on the ISC (IMS Subsystem Service Control) interface. This
header field conveys the identity of the served user and the session
case that applies to this particular communication session and
application invocation.
"VoIP Peering: Background and Assumptions", Otmar Lendl, 28-Oct-08,
<draft-lendl-speermint-background-02.txt>
This documents provides background for the work on VoIP peering and
tries to provide guidance on what kind of work is needed to
facilitate widespread SIP-based peering of telephony networks. It is
intended to spur discussion on the work about peering (in the
SPEERMINT and DRINKS WGs) and should also serve as input to the
ongoing discussions on reducing Spam for Internet Telephony (SPIT).
"Campus/Building Relative Location for Civic Location Format", Marc Linsner,
Allan Thomson, 14-Jul-08, <draft-linsner-geopriv-relativeloc-02.txt>
This document defines additional civic address parameters for use in
Location Objects [1], [2], and [4]. The format is based on the civic
address definition of PIDF-LO. These additional parameters allow
expression of a relative location within a building or campus.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application
Sub-Types", Jonathan Rosenberg, 12-Nov-07,
<draft-rosenberg-sip-app-media-tag-02.txt>
The caller preferences specification for the Session Initiation
Protocol (SIP) allows a caller to express preferences that the call
be routed to a User Agent (UA) with particular capabilities.
Similarly, a specification exists to allow a UA to indicate its
capabilities in a registration. Amongst those capabilities are the
type of media streams the agent supports, described as top-level MIME
types. The 'application' MIME type is used to describe a broad range
of stream types, and provides insufficient granularity as a
capability. This specification allows a UA to indicate which
application sub-types the agent supports.
"A Session Initiation Protocol (SIP) Extension for the Identification of
Services", Keith Drage, 20-Oct-08,
<draft-drage-sipping-service-identification-02.txt>
This document describes private extensions to the Session Initiation
Protocol (SIP) that enable a network of trusted SIP servers to assert
the service of authenticated users. The use of these extensions is
only applicable inside an administrative domain with previously
agreed-upon policies for generation, transport and usage of such
information. This document does NOT offer a general service
identification model suitable for use between different trust
domains, or use in the Internet at large.
The document also defines a URN to identify both services and UA
applications. This URN can be used to identify services within the
SIP header fields defined in this document, and also within the
framework defined for caller preferences and callee capabilities in
to identify usage of both services and applications between end UAs.
"Reclassification of the APEX RFCs to Historic", Marshall T. Rose, 4-Jun-07,
<draft-mrose-apex-historic-02.txt>
This memo reclassifies the APEX RFCs (RFCs 3340-3343) from PROPOSED
STANDARD to HISTORIC.
"Delay-Tolerant Networking Retransmission Block", Susan Symington, 31-Oct-08,
<draft-irtf-dtnrg-bundle-retrans-block-03.txt>
This document defines an optional extension block, called a
Retransmission Block, that may be used with the Bundle Protocol [2]
within the context of a Delay-Tolerant Network architecture [4]. The
Retransmission Block (RB) is designed to be inserted by a custodian
when re-forwarding a bundle, so as to mark the bundle as a legitimate
custody-based retransmission rather than an unauthorized bundle
duplicate. By providing a way for nodes that receive the re-
forwarded bundle to distinguish it from an unauthorized duplicate,
the RB enables those nodes whose local security policies do not
permit them to forward unauthorized duplicate bundles to detect and
delete unauthorized bundle duplicates but forward legitimate custody-
based bundle retransmissions. This document defines the format and
processing of this new Retransmission Block.
"Application Listener Discovery (ALD) for IPv6", James Woodyatt, 31-Jul-08,
<draft-woodyatt-ald-03.txt>
This document specifies the protocol used by IPv6 nodes comprising
stateful packet filters to discover the transport addresses of
listening applications (that is, application endpoints for which
incoming traffic may be administratively prohibited).
Comments are solicited and should be sent to the author and the V6OPS
Residential CPE Design Team mailing list at
<v6ops-residential-cpe-design-team@external.cisco.com>.
"An XCON Client Conference Control Package for the Media Control Channel
Framework", Chris Boulton, Mary Barnes, 20-Aug-08,
<draft-boulton-xcon-conference-control-package-03.txt>
The Centralized Conferencing framework defines a model whereby client
initiated interactions are required for creation, deletion,
manipulation and querying the state of a of conference. This
document defines a Media Control Channel Package for XCON client
initiated Conference Control. The Package is based on the Media
Control Channel Framework, which is also used for media server
control, thus optimizing the implementation for some entities
participating in an XCON system.
"Using Saratoga with a Bundle Agent as a Convergence Layer for Delay-Tolerant
Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson,
31-Oct-08, <draft-wood-dtnrg-saratoga-04.txt>
Saratoga is a simple, lightweight, UDP-based transfer protocol. This
describes how to use Saratoga as a Delay-Tolerant Networking (DTN)
"convergence layer" with the Bundle Protocol and its Bundle Agents,
building on the Saratoga specification in draft-wood-tsvwg-saratoga.
"802.1ah Ethernet Pseudowire", Luca Martini, Ali Sajassi, 25-Jul-08,
<draft-martini-pwe3-802.1ah-pw-03.txt>
An Ethernet Pseudowire (PW) is used to carry Ethernet/802.1ah frames
over an MPLS network. This enables service providers to offer
"emulated" Ethernet services over existing MPLS networks. This
document specifies the encapsulation of 802.1ah Ethernet Frames within a
pseudo wire. It also specifies the procedures for using a PW to provide a
"point-to-point Ethernet" service.
"LC-PCN: The Load Control PCN Solution", Lars Westberg, Anurag Bhargava,
Attila Bader, Georgios Karagiannis, Hein Mekkes, 3-Nov-08,
<draft-westberg-pcn-load-control-05.txt>
There is an increased interest of simple and scalable resource
provisioning solution for Diffserv network. The Load Control PCN
(LC-PCN) addresses the following issues:
o Admission Control for real time data flows in stateless Diffserv
Domains
o Flow Termination: Termination of flows in case of exceptional
events, such as severe congestion after re-routing.
Admission control in a Diffserv stateless domain can be performed
using two methods:
o Admission Control based on data marking, whereby in congestion
situations the data packets are marked to notify the PCN-egress-
node that a congestion occurred on a particular PCN-ingress-node
to PCN-egress-node path.
o Probing, whereby a probe packet is sent along the forwarding path
in a network to determine whether a flow can be admitted based
upon the current congestion state of the network
The scheme provides the capability of controlling the traffic load in
the network without requiring signaling or any per-flow processing in
the PCN-interior-nodes. The complexity of Load Control is kept to a
minimum to make implementation simple. LC-PCN can support the
ingress-egress-aggregate (i.e., trunk/pipe) bandwidth management
model as well as the HOSE bandwidth management model.
"Performance Analysis of Inter-Domain Path Computation Methodologies", Sukrit
Dasgupta, Jaudelice Oliveira, JP Vasseur, 14-Jul-08,
<draft-dasgupta-ccamp-path-comp-analysis-02.txt,.pdf>
This document presents a performance comparison between the per-
domain path computation method and the Path Computation Element (PCE)
Architecture based Backward Recursive Path Computation (BRPC)
procedure. Metrics to capture the significant performance aspects
are identified and detailed simulations are carried out on realistic
scenarios. A performance analysis for each of the path computation
methods is then undertaken.
"Multiple Packetization Times in the Session Description Protocol (SDP):
Problem Statement, Requirements & Solution", Marc Willekens, Miguel Garcia,
Peili Xu, 13-Jul-08, <draft-garcia-mmusic-multiple-ptimes-problem-03.txt>
This document provides a problem statement and requirements with
respect to the presence of a single packetization time (ptime/
maxptime) attribute in SDP media descriptions that contain several
media formats (audio codecs). Furthermore, a best common practice
solution for the use of 'ptime/maxptime' is proposed based on
'static', 'dynamic' and 'indicated' values. Some methods already
proposed as ad-hoc solutions and background information is included
in an appendix.
"Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value
Pair (AVP) Extensions", Vince Mammoliti, Carlos Pignataro, Peter Arberg, John
Gibbons, Paul Howard, 18-Nov-08, <draft-mammoliti-l2tp-accessline-avp-04.txt>
This document describes a set of Layer 2 Tunneling Protocol (L2TP)
Attribute Value Pair (AVP) extensions designed to carry the
subscriber Access Line identification and characterization
information that arrives at the Broadband Remote Access Server (BRAS)
with LAC functionality. It also describes a mechanism to report
connection speed changes, after the initial connection speeds are
sent during session establishment. The primary purpose of this
document is to provide a reference for DSL equipment vendors wishing
to interoperate with other vendors' products. The L2TP AVPs defined
in this document are applicable to both L2TPv2 and L2TPv3.
"Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Gorry
Fairhurst, Thomas Schmidt, Matthias Waehlisch, 18-Nov-08,
<draft-irtf-mobopts-mmcastv6-ps-05.txt>
This document discusses current mobility extensions to IP layer
multicast. It describes problems arising from mobile group
communication in general, the case of multicast listener mobility,
and for mobile senders using Any Source Multicast and Source Specific
Multicast. Characteristic aspects of multicast routing and deployment
issues for fixed IPv6 networks are summarized. Specific properties
and interplays with the underlying network access are surveyed with
respect to the relevant technologies in the wireless domain. It
outlines the principal approaches to multicast mobility, together
with a comprehensive exploration of the mobile multicast problem and
solution space. This document concludes with a conceptual roadmap for
initial steps in standardization for use by future mobile multicast
protocol designers.
"IPv6 Configuration in IKEv2", Pasi Eronen, Julien Laganier, Cheryl Madson,
28-Oct-08, <draft-eronen-ipsec-ikev2-ipv6-config-05.txt>
When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. This document describes the
limitations of current IKEv2 configuration payloads for IPv6, and
explores possible solutions that would allow IKEv2 to set up full-
featured virtual IPv6 interfaces.
"Timezone Information in HTTP", Stefanos Harhalakis, 1-Oct-08,
<draft-sharhalakis-httptz-04.txt>
This document defines a HTTP header for clients to provide timezone
information to web servers. An ABNF description of the corresponding
header is provided.
"Handle Resolution Option for ASAP", Thomas Dreibholz, 4-Oct-08,
<draft-dreibholz-rserpool-asap-hropt-03.txt>
This document describes the Handle Resolution option for the ASAP
protocol.
"Media Resource Brokering", Chris Boulton, 28-Oct-08,
<draft-boulton-mediactrl-mrb-03.txt>
The MediaCtrl work group in the IETF is currently proposing an
architecture for controlling media services. The Session Initiation
Protocol(SIP) will be used as the signalling protocol which provides
many inherent capabilities for message routing. In addition to such
signalling properties, a need exists for intelligent, application
level media service selection based on non-static signalling
properties. This is especially true when considered in conjunction
with deployment architectures that include 1:M and M:M combinations
of Application Servers and Media Servers.
"TLS using EAP Authentication", Yoav Nir, Hannes Tschofenig, Peter Gutmann,
8-Jul-08, <draft-nir-tls-eap-04.txt>
This document describes an extension to the TLS protocol to allow TLS
clients to authenticate with legacy credentials using the Extensible
Authentication Protocol (EAP).
This work follows the example of IKEv2, where EAP has been added to
the IKEv2 protocol to allow clients to use different credentials such
as passwords, token cards, and shared secrets.
When TLS is used with EAP, additional records are sent after the
ChangeCipherSpec protocol message and before the Finished message,
effectively creating an extended handshake before the application
layer data can be sent. Each EapMsg handshake record contains
exactly one EAP message. Using EAP for client authentication allows
TLS to be used with various AAA back-end servers such as RADIUS or
Diameter.
TLS with EAP may be used for securing a data connection such as HTTP
or POP3. We believe it has three main benefits:
o The ability of EAP to work with backend servers can remove that
burden from the application layer.
o Moving the user authentication into the TLS handshake protects the
presumably less secure application layer from attacks by
unauthenticated parties.
o Using mutual authentication methods within EAP can help thwart
certain classes of phishing attacks.
"Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas
Chevrollier, Dominik Kaspar, JP Vasseur, 14-Jul-08,
<draft-ekim-6lowpan-scenarios-03.txt>
This document investigates potential application scenarios and use
cases for low-power wireless personal area networks (LoWPANs).
"Use of the Identity-Based Cryptographic Algorithms in CMS", Zhaohui Cheng,
Bo Dan, 19-Oct-08, <draft-cheng-smime-ibccms-05.txt>
This document describes the conventions for using identity-based
cryptography algorithms in the Cryptographic Message Syntax (CMS).
"EAP-Based Keying for IP Mobility Protocols", Vidya Narayanan, Gerardo
Giaretta, 16-Nov-07, <draft-vidya-eap-usrk-ip-mobility-01.txt>
EAP [1] is increasingly used for network access authentication in
various networks. Also, key generating EAP methods are being adopted
in various systems for the purposes of cryptographic protection
between an EAP peer and an enforcement point in the network. Key
generating EAP methods produce an MSK and an EMSK in accordance with
[1]. The MSK is meant for use by the EAP lower layer at the peer and
the authenticator and is used differently by various lower layers.
The EMSK hierarchy is defined in [2]. The EMSK hierarchy is meant to
be extensible to derive keys for various usages. This document
defines the key hierarchy and key derivations for using the EMSK
hierarchy for keying in IP mobility protocols.
"Definition of a Delay Measurement Infrastructure and Delay-Sensitive
Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou,
11-Jul-08, <draft-dreibholz-rserpool-delay-02.txt>
This document contains the definition of a delay measurement
infrastructure and a delay-sensitive Least-Used policy for Reliable
Server Pooling.
"A Framework to tackle Spam and Unwanted Communication for Internet
Telephony", Hannes Tschofenig, Henning Schulzrinne, Dan Wing, Jonathan
Rosenberg, David Schwartz, 14-Jul-08,
<draft-tschofenig-sipping-framework-spit-reduction-04.txt>
Spam, defined as sending unsolicited messages to someone in bulk, is
likely to become a problem on SIP open-wide deployed networks. A
number of solutions have been proposed for dealing with Spam for
Internet Telephony (SPIT) and unwanted communication, such as content
filtering, black lists, white lists, consent-based communication,
reputation systems, address obfuscation, limited use addresses,
turing tests, computational puzzles, payments at risk, circles of
trust, and many others.
This document describes the big picture that illustrates how the
different building blocks fit together and can be deployed
incrementally.
"Requirements for Authorization Policies to tackle Spam and Unwanted
Communication for Internet Telephony", Hannes Tschofenig, Geoffrey Dawirs,
Thomas Froment, Dan Wing, Henning Schulzrinne, 11-Jul-08,
<draft-froment-sipping-spit-requirements-03.txt>
Spam over Internet Telephony (SPIT) is one of the foreseen future
forms of spamming that SIP open-wide networks may have to handle.
SPIT also has more impact on users than email spam since it is more
intrusive. Email as a store-and-forward communication mechanism
allows for several filtering mechanisms to be applied to the full
content before being presented to the user. Session Initiation
Protocol (SIP) interaction is, in contrast, real-time communication
and therefore does not provide much information prior to the
transmission of the content, making it both harder to filter and more
annoying to users. The responsibility for filtering, blocking calls,
or taking any other preventive action can belong to different
elements in the call flow and may depend on various factors. This
document discusses the requirements to define authorization policies
that should allow end users or other parties to setup anti-SPIT
policies for triggering these actions. These policies typically
match a particular SIP communication pattern based on a number of
attributes. The range of attributes includes information provided,
for example, by the SIP protocol itself, by the SIP identity
mechanism, by information carried within SAML assertions or by
reputation systems of social networks.
"MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode", Alexandre Barreto,
Antonio Faleiros, 18-Jun-07, <draft-barreto-ietf-dhhmac-sas-00.txt>
This document presents a new transport mode to the Multimedia
Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has
as its objective the negotiation of cryptography parameters
necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end
multimedia channel, but all its operation modes have some kind of
limitation that prevents it of being used to this purpose. The
MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and
MIKEY-DHHMAC modes by adding the features of key continuity and Short
Authentication String (SAS), making possible its use in any end-to-
end multimedia scenario.
"Commissioning in 6LoWPAN", Ki-Hyung Kim, Chae-Seong Lim, Seung Yoo, Soohong
Daniel Park, Geoffrey Mulligan, 17-Jul-08,
<draft-daniel-6lowpan-commissioning-02.txt>
The commisioning process defines the startup procedure executed by
any 6LoWPAN device. This document defines the startup procedure that
should be followed by a 6LoWPAN device in any open or secured
network.
"Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida
Schubert, Takumi Ohba, 25-Sep-08,
<draft-munakata-sip-privacy-guideline-04.txt>
This is an informational document that provides guidelines for using
the privacy mechanism for Session Initiation Protocol (SIP), that is
specified in RFC 3323 and subsequently extended in RFCs 3325 and
4244. It is intended to clarify the handling of the target SIP
headers/parameters and SDP parameters for each of the privacy header
values (priv-values).
"ECC Brainpool Standard Curves and Curve Generation", Manfred Lochter,
Johannes Merkle, 4-Aug-08, <draft-lochter-pkix-brainpool-ecc-02.txt>
This Memo proposes several elliptic curve domain parameters over
finite prime fields for use in cryptographic applications. The
domain parameters are consistent with the relevant international
standards, and can be used in X.509 certificates and certificate
revocation lists (CRLs), for Internet Key Exchange (IKE), Transport
Layer Security (TLS), XML signatures, and all applications or
protocols based on the cryptographic message syntax (CMS).
"REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp,
Eric Rescorla, Salman Baset, Henning Schulzrinne, 10-Jun-08,
<draft-bryan-p2psip-reload-04.txt>
This document 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 which do not need to route traffic or store data
for others.
"Header Protection for S/MIME", Lijun Liao, Joerg Schwenk, 6-Oct-08,
<draft-liao-smimeheaderprotect-03.txt>
In the current S/MIME Version 3.1 specification, the header
protection is achieved by encoding the whole message as a
message/rfc822 MIME object. Since this approach poses some practical
problems, we propose to use signed attributes to implement a fully
backward compatible S/MIME header protection scheme.
"HELD Protocol Context Management Extensions", James Winterbottom, Hannes
Tschofenig, Martin Thomson, 29-Sep-08,
<draft-winterbottom-geopriv-held-context-03.txt>
This document describes a protocol extension for the HTTP Enabled
Location Delivery (HELD) protocol. It allows a Target to manage
their location information on a Location Information Server (LIS)
through the application of constraints invoked by accessing a
location URI. Constraints described in this memo restrict how often
location can be accessed through a location URI, how long the URI is
valid for, and the type of location information returned when a
location URI is accessed. Extension points are also provided.
"Correct transaction handling for 200 responses to Session Initiation
Protocol INVITE requests", Robert Sparks, 3-Jul-08,
<draft-sparks-sip-invfix-02.txt>
This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address an error in the specified handling of
success (200 class) responses to INVITE requests. Elements following
RFC 3261 exactly will misidentify retransmissions of the request as a
new, unassociated, request. The correction involves modifying the
INVITE transaction state machines. The correction also changes the
way responses that cannot be matched to an existing transaction are
handled to address a security risk.
"Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local
Mobility Anchor to Diameter Server Interaction", Jouni Korhonen, Julien
Bournelle, Ahmad Muhanna, Kuntal Chowdhury, Ulrike Meyer, 15-Sep-08,
<draft-korhonen-dime-pmip6-04.txt>
This specification defines the Diameter support for the Proxy Mobile
IPv6 and the corresponding mobility service session setup. The
policy information needed by the Proxy Mobile IPv6 is defined in
mobile node's policy profile, which could be downloaded from the
Diameter server to the Mobile Access Gateway once the mobile node
roams into a Proxy Mobile IPv6 Domain and performs access
authentication.
"Delay Tolerant Networking TCP Convergence Layer Protocol", Michael Demmer,
Jörg Ott, 3-Nov-08, <draft-irtf-dtnrg-tcp-clayer-02.txt>
This document describes the protocol for the TCP-based Convergence
Layer for Delay Tolerant Networking (DTN).
"Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel
Suignard, 3-Aug-08, <draft-duerst-iri-bis-04.txt>
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.
[RFC Editor: Please remove this paragraph before publication.] This
is a draft to update RFC 3987 and move towards IETF Draft Standard.
For an issues list/change log and additional information (including
mailing list information), please see
http://www.w3.org/International/iri-edit. For discussion and
comments on this draft, please use the public-iri@w3.org mailing
list.
"The use of SVEC (Synchronization VECtor) list for Synchronized dependent
path computations", Itaru Nishioka, Daniel King, 4-Jul-08,
<draft-nishioka-pce-svec-list-02.txt>
A Path Computation Element (PCE) performing dependent path
computations, for instance calculating a diverse working and
protected path do not share common network points, would need to
synchronize the computations in order to increase the probability
of meeting the working and protected path disjoint objective and
network resource optimization objective. When a PCE computes
multiple sets of dependent path computation requests concurrently,
it is required to use Synchronization VECtor (SVEC) list for
association among the sets of dependent path computation requests.
This document describes the usage of multiple SVECs in the SVEC
list and its processing guideline, for the synchronized computation
of dependent paths.
"MIPv4 Authentication Using a New Diameter MIPv4 Application", Ahmad Muhanna,
Mohamed Khalil, Avi Lior, 14-Jul-08,
<draft-muhanna-diameter-mip4-performance-02.txt>
Current Mobile IPv4 deployments use RADIUS based MIPv4 user
authentication and authorization. Diameter Mobile IPv4 Application
[RFC4004] offers another method for MIPv4 authentication,
authorization, and dynamic mobility security association allocation,
e.g. MN-HA SA allocation. Some SDOs are considering the use of
Diameter Mobile IPv4 Application to replace RADIUS based mechanism.
However, these SDos use a link layer access authentication mechanism,
e.g., using an EAP application, to derive the related MIP4 shared
keys and security association. This document an overview of these
respected architectures and their handling to MIP4 security
association and keys derivation and distribution. It presents an
analysis of the performance and impact of Diameter MIPv4 Application
and RADIUS based solutions on the time the mobile node uses during
the initial session setup. Some common MIPv4 scenarios which require
the mobile node to retransmit its initial RRQ message have been
identified and used. The set of assumptions and requirements used
for this study has been clearly documented under section 5.
"ANCP Multicast Handling Sessions", Roberta Maglione, Angelo Garofalo,
Francois Le Faucheur, Toerless Eckert, Tom Taylor, 11-Jul-08,
<draft-maglione-ancp-mcast-01.txt>
This memorandum aims at presenting ANCP Multicast handling. It
proposes updated description of the Multicast Use cases and
corresponding updated ANCP requirements. It also presents the
corresponding Message Flows.
"Layered Encapsulation of Congestion Notification", Bob Briscoe, 14-Jul-08,
<draft-briscoe-tsvwg-ecn-tunnel-01.txt>
This document redefines how the explicit congestion notification
(ECN) field of the outer IP header of a tunnel should be constructed.
It brings all IP in IP tunnels (v4 or v6) into line with the way
IPsec tunnels now construct the ECN field. It includes a thorough
analysis of the reasoning for this change and the implications. It
also gives guidelines on the encapsulation of IP congestion
notification by any outer header, whether encapsulated in an IP
tunnel or in a lower layer header. Following these guidelines should
help interworking, if the IETF or other standards bodies specify any
new encapsulation of congestion notification.
"Emulating Border Flow Policing using Re-PCN on Bulk Data", Bob Briscoe,
13-Sep-08, <draft-briscoe-re-pcn-border-cheat-02.txt>
Scaling per flow admission control to the Internet is a hard problem.
The approach of combining Diffserv and pre-congestion notification
(PCN) provides a service slightly better than Intserv controlled load
that scales to networks of any size without needing Diffserv's usual
overprovisioning, but only if domains trust each other to comply with
admission control and rate policing. This memo claims to solve this
trust problem without losing scalability. It provides a sufficient
emulation of per-flow policing at borders but with only passive bulk
metering rather than per-flow processing. Measurements are
sufficient to apply penalties against cheating neighbour networks.
"RADIUS Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri
Gundavelli, 3-Nov-08, <draft-xia-netlmm-radius-03.txt>
This document defines a RADIUS based interface between the Mobile
Access Gateway and the RADIUS server that is used to download the per
Mobile Node Policy Profile from the remote Policy Store. The RADIUS
interactions take place when the Mobile Node attaches, authenticates
and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this
document also defines a RADIUS based interface between the Local
Mobility Anchor and the RADIUS server for authorizing received
initial Proxy Binding Update messages for the mobility service
session. In addition to the mobility session setup related RADIUS
interaction, this document defines the baseline for both the Mobile
Access Gateway and the Local Mobility Anchor generated accounting.
"OpenToken", Dave Smith, Peter Motykowski, Yasir Faruqi, Peter Saint-Andre,
11-Aug-08, <draft-smith-opentoken-02.txt>
This document describes OpenToken (OTK), a format for the
lightweight, secure, cross-application exchange of key-value pairs.
The format is designed primarily for use as an HTTP cookie or query
parameter, but can also be used in other scenarios that require a
compact, application-neutral token.
"Applicability Issues of IPsec in NAT-PT", Sangjin Jeong, Myung-Ki Shin,
Sangdo Lee, 3-Nov-08, <draft-lee-ipsec-nat-pt-applicability-03.txt>
NAT-PT (Network Address Translation - Protocol Translation) mechanism
that has been deprecated in [RFC4966] comes into spotlight again.
The use-cases that NAT-PT addresses still need to be discussed and
the requirements persist in IPv6 transition work. This document
discusses the applicability issues when applying IPsec protocol to
NAT-PT mechanism.
"IPv4 Mobility Extension for Multicast and Broadcast Packets", Samita
Chakrabarti, Ahmad Muhanna, Gabriel Montenegro, Yingzhe Wu, Basavaraj Patil,
30-Oct-08, <draft-chakrabarti-mip4-mcbc-03.txt>
This document define a new Mobile IPv4 extension which is used with
Mobile IPv4 signaling to negotiate the Multicast-Broadcast
Encapsulation Delivery style in the case of Foreign Agent Care-of-
Address mode registration. This mechanism allows the mobile node to
negotiate which type of traffic to be delivered encapsulated to the
foreign agent while delivering other types of IP packets using direct
delivery style. In particular, this mechanism will give flexibility
to eliminate tunnel overhead in the (typically) wireless medium
between the mobile node and the foreign agent.
"VPLS Extensions for Provider Backbone Bridging", Matthew Bocci, John
Hoffmans, Geraldine Calvignac, Raymond Zhang, Florin Balus, 15-Jul-08,
<draft-balus-l2vpn-vpls-802.1ah-03.txt>
IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider
Backbone Bridges (PBB) defines an architecture and bridge protocols
for interconnection of multiple Provider Bridge Networks (PBNs). PBB
was defined in IEEE as a connectionless technology based on
multipoint VLAN tunnels. MSTP is used as the core control plane for
loop avoidance and load balancing. As a result, the coverage of the
solution is limited by STP scale in the core of large service
provider networks.
Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without running (M)STP across the
backbone. As a result, VPLS has been deployed on a large scale in
service provider networks.
This draft discusses extensions to the VPLS model required to
incorporate desirable PBB components while maintaining the Service
Provider fit of the initial model.
"Fast Handovers for PMIPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev
Koodli, Basavaraj Patil, Frank Xia, 13-Jul-08,
<draft-yokota-mipshop-pfmipv6-03.txt>
This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is
applied for the mobility management protocol. Necessary amendments
are shown for FMIPv6 to work under the condition that the mobile node
does not have IP mobility functionality and it is not involved with
either MIPv6 or FMIPv6 operations.
"Additional Location Privacy Considerations", Richard Barnes, Matt Lepinski,
Hannes Tschofenig, Henning Schulzrinne, 14-Jul-08,
<draft-barnes-geopriv-lo-sec-03.txt>
This document discusses security and privacy concerns related to the
distribution of location information over the Internet. We clarify
how privacy rules can be enforced by a location server, and how
privacy rules should be interpreted in store and forward networks.
We also describe general mechanisms for providing end-to-end
assurances about a location object.
"Requirements for Authority-to-Individuals Communication for Emergency
Situations", Steve Norreys, 14-Jul-08,
<draft-norreys-ecrit-authority2individuals-requirements-01.txt>
Public safety agencies need to provide information to the general
public before and during large-scale emergencies. While many aspects
of such systems are specific to national or local jurisdictions,
emergencies span such boundaries and notifications need to reach
visitors from other jurisdictions. This document summarizes
requirements for protocols to alert individuals within a defined
geographic area.
"Session Initiation Protocol (SIP) Event Package for the Common Alerting
Protocol (CAP)", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig,
12-Jul-08, <draft-rosen-sipping-cap-02.txt>
The Common Alerting Protocol (CAP) is an XML document format for
exchanging emergency alerts and public warnings. This document
allows CAP documents to be distributed via the event notification
mechanism available with the Session Initiation Protocol (SIP).
"Membership Event Package", Vishal Singh, Henning Schulzrinne, Piotr Boni,
14-Jul-08, <draft-singh-simple-membership-01.txt>
This document defines a new event membership package that allows to
track changes in membership in groups. Groups can represent entities
contained within a physical space, such as a room or vehicle, or a
logical group of entities, such as a call center team. Each member
of a group can support a different set of event packages.
"Requirements for configuring Cryptographically Generated Addresses (CGA) and
overview on RA and DHCPv6-based approaches", Sheng Jiang, 11-Jul-08,
<draft-jiang-sendcgaext-cga-config-02.txt>
This document analyzes the requirements for the configuration
Cryptographically Generated Addresses and Multi-key CGAs. The
applicability of Router Advertisement and DHCPv6 for this
configuration is also discussed.
"An Evaluation Framework for Data Modeling Languages in Network Management
Domain", Hui Xu, Debao Xiao, 3-Nov-08, <draft-xiao-evaluate-dml-03.txt>
With rapid development of next generation networks, it is expected
that a separate effort to study data modeling languages in the
interest of network management should be undertaken. Based on a good
understanding of the requirements of data modeling in next generation
network management domain, evaluation on management data modeling
languages becomes an essential way for the purpose of standardization
to replace proprietary data models in the near future. Our project
aims to establish a framework for evaluation to measure the
capabilities of management data modeling languages in meeting those
requirements by a set of criteria, which are modeling approaches,
interoperability, readability, conformance, data representation,
extensibility and security considerations.
"File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray,
14-Jul-08, <draft-hethmon-mcmurray-ftp-hosts-01.txt>
The File Transfer Protocol, as defined in RFC 959 [1] and RFC 1123
Section 4 [6], is one of the oldest and widely used protocols on the
Internet.
This document addresses the subject of creating multi-homed FTP hosts
servers on a single IP address. This is achieved by extending the
FTP specification to add a HOST command that is used to specify
individual FTP hosts.
"Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions",
Minpeng Qi, Haitao Li, Peng Yang, Hui Deng, Yuanchen Ma, 14-Jul-08,
<draft-qi-mip6-ikev2-interfacing-02.txt>
This draft discusses the issues associated with interfacing between
IKEv2/IPsec and MIPv6. When mobile nodes bootstrap in foreign
network or handover to a new network, IKEv2/IPsec can not probe the
changing of care-of-address, which is related security associations.
One simple extension to the SADB_ACQUIRE in PF_KEY framework is
proposed to support this interfacing. And the operation modification
of IKEv2 and MIPv6 are described in this proposal based on the
SADB_ACQUIRE extension. A new mobility security reference database
is created to store the temporary mobility parameters.
"Open Research Issues in Internet Congestion Control", Dimitri Papadimitriou,
8-Aug-08, <draft-irtf-iccrg-welzl-congestion-control-open-research-02.txt>
This document describes some of the open problems in Internet
congestion control that are known today. This includes several new challenges
that are becoming important as the network grows, as well as some issues
that have been known for many years. These challenges are generally considered
to be open research topics that may require more study or application of
innovative techniques before Internet- scale solutions can be confidently
engineered and deployed.
"PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 30-Jun-08,
<draft-pala-prqp-02.txt>
One of the most strategic problems still open in PKIX is locating
public data and services associated with a Certification Authority
(CA). This issue impacts interoperability and usability in PKIX.
This draft describes the PKI Resource Query Protocol (PRQP), its
design, definition, and its impact in already deployed PKIX
protocols.
"A Solution For Source Address Validation in Local Subnet Environment",
Jianping Wu, Gang Ren, Jun Bi, Xing Li, Mark Williams, 14-Jul-08,
<draft-wu-sava-solution-firsthop-eap-01.txt>
This document describes a solution for preventing source address
spoofing in the local subnet of the Internet. The main idea of the
solution is to get a dynamic binding between IP address and access
switch port.
"Administrative Specific Elements for Civic Location Format", Marc Linsner,
Subha Dhesikan, Hannes Tschofenig, 14-Jul-08,
<draft-linsner-geopriv-adminspecific-01.txt>
This document defines additional civic address parameters for use in
Location Objects [1], [2], and [4]. The format is based on the civic
address definition of PIDF-LO. These addition parameters allow
expression of administrative specific location data elements.
"Ivip (Internet Vastly Improved Plumbing) Architecture", Robin Whittle,
19-Aug-08, <draft-whittle-ivip-arch-02.txt>
Ivip (Internet Vastly Improved Plumbing) is a proposed global system
of routers and either collection of databases which control the
tunneling of some of these routers. Database changes affect all
Ingress Tunnel Routers (ITRs) within a few seconds, controlling which
Egress Tunnel Router (ETR) they tunnel each packet to, depending on
the packet's destination address. The ETR used by a host with an
Ivip-mapped address is typically located in the same network as this
destination host. The ETR decapsulates packets and forwards them to
the destination host. A second type of ETR known as a Translating
Tunnel Router (TTR) is used for mobile-IP, with the mobile node
creating two-way tunnels to one or more nearby TTRs. Ivip enables a
subset of IPv4 and IPv6 address space to be portable (used via any
ISP which has an ETR) and to be suitable for multihoming (connection
to the Net via two or more ISPs) - without involving BGP and without
requiring any changes to host operating systems or applications.
This is a form of "locator-ID separation" and is based on some
principles derived from LISP (Locator/ID Separation Protocol). IP
addresses in the subset of address space which is subject to being
tunneled by ITRs are known as Destination Identifiers (DIDs). ITRs
and ETRs are located on ordinary BGP Reachable IP (BRIP) addresses.
The databases and ITRs map DID addresses to an ETR's BRIP address
with a granularity of a single IPv4 address or a /64 prefix for IPv6.
These two granularities are 256 and 64k times finer than is typically
possible with BGP. This proposal is intended to resolve many of the
problems discussed in the October 2006 Amsterdam IAB Routing and
Addressing Workshop (RAWS). Ivip's primary goals include the more
efficient utilisation of IPv4 space and enabling millions of end-
users to achieve portability and multihoming without involving BGP,
without fuelling the growth of the global BGP routing table, and
without requiring these end users to have ASNs or to acquire
conventional prefixes of PI (Provider Independent) BGP reachable
address space.
"Link Metrics for OLSRv2", Christopher Dearlove, Thomas Clausen, Philippe
Jacquet, 16-Sep-08, <draft-dearlove-olsrv2-metrics-03.txt>
This document describes how link metrics may be added, in a
relatively straightforward manner, to the specification of OLSRv2, in
order to allow routing by other than minimum hop count routes. In
addition to metric signaling and use, the most significant change is
a separation of the routing and flooding functions of MPRs.
"EAP Fast Re-Authentication Protocol (EAP-FRAP)", Saber Zrelli, Yoichi
Shinoda, 3-Jun-08, <draft-zrelli-eap-frap-04.txt>
This document specifies an extension to the AAA/EAP authentication
and key management framework that allows an EAP peer to perform fast
re-authentications with the local EAP server after an initial full
EAP authentication using a legacy EAP method with the same or another
EAP server. EAP-FRAP eliminates the need for exchanges between the
local EAP server and the home EAP server each time the EAP peers is
authenticated. In wireless networks, this allows the mobile device
to reduce hand-off delays. The EAP-FRAP extension does not require
changes in underlying layer protocols. Which makes is back-ward
compatible with existing infrastructures and easily deployable with
minimal costs.
"The Lightweight Global Navigation Satellite System (GNSS) Support Protocol
(LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07, <draft-tyson-lgsp-01.txt>
This document presents the Lightweight GNSS (Global Navigation
Satellite System) Support Protocol (LGSP). The Lightweight GNSS
Support Protocol (LGSP) is being developed in order to provide a
comprehensive solution which solves the problems inherent in
traditional radio-based Differential GPS (DGPS) protocols. LGSP will
also provide additional support for GNSS user equipment, such as a
GPS almanac retrieval method, allowing compatible units to perform
faster almanac acquisition, thus resulting in less time until an
initial position measurement can be established. Other supporting
features include alternative distribution of GPS navigation messages
and differential correction messages, a hierarchical mirroring
architecture, redundant backup operation and load balancing
functions.
"Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance
Networks", Murali Sridharan, Kun Tan, Deepak Bansal, Dave Thaler, 11-Nov-08,
<draft-sridharan-tcpm-ctcp-02.txt>
Compound TCP (CTCP) is a modification to TCP's congestion control
mechanism for use with TCP connections with large congestion windows.
This document describes the Compound TCP algorithm in detail, and
solicits experimentation and feedback from the wider community. The
key idea behind CTCP is to add a scalable delay-based component to the
standard TCP's loss-based congestion control. The sending rate of CTCP
is controlled by both loss and delay components. The delay-based
component has a scalable window increasing rule that not only
efficiently uses the link capacity, but on sensing queue build up,
proactively reduces the sending rate.
"Redesignation of 240/4 from "Future Use" to "Private Use"", Paul Wilson,
George Michaelson, Geoff Huston, 29-Sep-08, <draft-wilson-class-e-02.txt>
This document directs the IANA to designate the block of IPv4
addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast
address space for Private Use.
"RAN Synchronization Requirements", LinLang Zhou, 7-Jul-08,
<draft-zhou-tictoc-ran-sync-req-01.txt>
This Internet draft describes RAN synchronization requirements,
mainly about synchronization description and requirements, also includes
some applications and problem description.
"Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen
McCann, Gabor Bajko, Hannes Tschofenig, 3-Nov-08,
<draft-schulzrinne-ecrit-unauthenticated-access-04.txt>
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 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.
""RTP Payload Format for apt-X"", Gregory Massey, 24-Jun-08,
<draft-gmassey-avt-rtp-aptx-02.txt>
This document describes an RTP payload format for transporting apt-X
encoded audio. It details the RTP encapsulation mechanism for
standard, enhanced apt-X and apt-X Live data. Also included within
this memo are media type registrations, and the details necessary for
the use of apt-X, enhanced apt-X and apt-X Live with the Session
Description Protocol.
"Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs",
Hassnaa Moustafa, Carlos Bernardos, Maria Calderon, 1-Nov-08,
<draft-bernardos-autoconf-evaluation-considerations-03.txt>
This Internet Draft aims at providing general guidelines for the
AUTOCONF solution space, through providing a set of evaluation
considerations for IP autoconfiguration mechanisms in MANETs. These
evaluation considerations conform to the AUTOCONF problem statement
draft and the MANET architecture draft. The main objective of this
draft is to illustrate some key features and highlight some important
behaviours for the different autoconf mechanisms, and thus aiming to
help solution developers during mechanisms' design and to help
implementers in the choice of the autoconf mechanism that fits better
their particular requirements, taking into consideration a number of
important factors that are discussed in this draft.
"A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain
Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba,
Kenichi Taniuchi, Henning Schulzrinne, 2-Nov-08,
<draft-irtf-mobopts-mpa-framework-04.txt>
This document describes a framework of Media-independent Pre-
Authentication (MPA), a new handover optimization mechanism that
addresses the issues on existing mobility management protocols and
mobility optimization mechanisms to support inter-domain handover.
MPA is a mobile-assisted, secure handover optimization scheme that
works over any link-layer and with any mobility management protocol
and is best applicable to support optimization during inter-domain
handover. MPA's pre-authentication, pre-configuration, and proactive
handover techniques allow many of the handoff related operations to
take place before the mobile has moved to the new network. We
describe the details of all the associated techniques and its
applicability for different scenarios involving various mobility
protocols during inter-domain handover.
"Basic Password Exchange within the Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget,
Hao Zhou, 2-Nov-08, <draft-zhou-emu-fast-gtc-05.txt>
The flexible authentication via secure tunneling EAP method (EAP-
FAST) enables secure communication between a peer and a server by
using Transport Layer Security (TLS) to establish a mutually
authenticated tunnel. Within this tunnel a basic password exchange,
based on the generic token card method (EAP-GTC), may be executed to
authenticate the peer.
"CUBIC for Fast Long-Distance Networks", Injong Rhee, Lisong Xu, Sangtae Ha,
26-Aug-08, <draft-rhee-tcpm-cubic-02.txt>
CUBIC is an extension to the current TCP standards. The protocol
differs from the current TCP standards only in the congestion window
adjustment function in the sender side. In particular, it uses a
cubic function instead of a linear window increase of the current TCP
standards to improve scalability and stability under fast and long
distance networks. BIC-TCP, a predecessor of CUBIC, has been a
default TCP adopted by Linux since year 2005 and has already been
deployed globally and in use for several years by the Internet
community at large. CUBIC is using a similar window growth function
as BIC-TCP and is designed to be less aggressive and fairer to TCP in
bandwidth usage than BIC-TCP while maintaining the strengths of BIC-
TCP such as stability, window scalability and RTT fairness. Through
extensive testing in various Internet scenarios, we believe that
CUBIC is safe for deployment and testing in the global Internet. The
intent of this document is to provide the protocol specification of
CUBIC for a third party implementation and solicit the community
feedback through experimentation on the performance of CUBIC. We
expect this document to be eventually published as an experimental
RFC.
"OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi,
21-Sep-08, <draft-acee-ospf-multi-instance-02.txt>
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.
"Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti
Mäkelä, Jouni Korhonen, 31-Oct-08, <draft-makela-mip4-nemo-haaro-03.txt>
This document describes a Home Agent assisted route optimization
extension to IPv4 Network Mobility Protocol.
"Checksum Ciphersuites for the Bundle Protocol", Wesley Eddy, Lloyd Wood,
Will Ivancic, 31-Oct-08, <draft-irtf-dtnrg-bundle-checksum-03.txt>
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.
This document attempts to address the situation by defining new
ciphersuites for use within the existing Bundle Security Protocol's
Payload Integrity Block (formerly called the Payload Security Block)
to provide error-detection functions regardless of an
implementation's support for other, more complex, security-providing
ciphersuites. This creates the checksum service needed for error-
free reliability, but does so at the expense of divorcing security
concerns from the few new reliability-only ciphersuite definitions
that are introduced here. This document lengthily discusses the pros
and cons of this approach and the existing constraints that combined
to drive this design.
"Diameter Support for EAP Re-authentication Protocol", Lakshminath Dondeti,
14-Jul-08, <draft-dondeti-dime-erp-diameter-02.txt>
An EAP extension, called "EAP Re-authentication Protocol (ERP)", has
been specified that supports an EAP method-independent protocol for
efficient re-authentication between the peer and the server through
an authenticator. This document specifies Diameter support for ERP.
The Diameter EAP application is re-used for encapsulating the newly
defined EAP Initiate and EAP Finish messages specified in the ERP
specification. AVPs for request and delivery of Domain Specific Root
Keys from the AAA/EAP server to the ER server are also specified.
Additionally, this document also specifies Diameter processing rules
relevant to ERP.
"Connection setup negociation for the Message Session Relay Protocol", Remi
Denis-Courmont, 27-Jul-08, <draft-denis-simple-msrp-comedia-02.txt>
This document extends the MSRP connection model to negotiate the
direction of the TCP connection setup. This provides a partial yet
simple solution for scenarios whereby either, but not both, party to
an MSRP session is located behind a NAT or firewall, and cannot serve
as the passive endpoint for TCP connection setup.
"H.248/MEGACO Package Registration Procedures", Christian Groves, Yangbo Lin,
31-Jul-08, <draft-groves-megaco-pkgereg-02.txt>
This document updates the H.248/MEGACO IANA Package Registration
procedures in order to better describe the Package registration
process and to provide a more formal review and feedback process.
"Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa
Andersson, 4-Oct-08, <draft-iab-ip-config-08.txt>
This document describes principles of Internet host configuration.
It covers issues relating to configuration of Internet layer
parameters, as well as parameters affecting higher layer protocols.
"IPsec Gateway Failover Protocol", Yaron Sheffer, Hannes Tschofenig,
Lakshminath Dondeti, Vidya Narayanan, 12-Jul-08,
<draft-sheffer-ipsec-failover-04.txt>
The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
is used for authentication, which adds several more round trips and
therefore latency.
To re-establish security associations (SA) upon a failure recovery
condition is time consuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.
In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously
established IKE SA.
A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with
the previous one. The proposed approach conveys IKEv2 state
information, in the form of an encrypted ticket, to a VPN client that
is later presented to the VPN gateway for re-authentication. The
encrypted ticket can only be decrypted by the VPN gateway in order to
restore state for faster session setup.
"Using Device-provided Location-Related Measurements in Location
Configuration Protocols", Martin Thomson, James Winterbottom, 28-Oct-08,
<draft-thomson-geopriv-held-measurements-03.txt>
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.
"URI Scheme for Java(tm) Message Service 1.0", Roland Merrick, Peter Easton,
Derek Rokicki, Eric Johnson, 17-Nov-08, <draft-merrick-jms-uri-05.txt>
This document defines the format of Uniform Resource Identifiers
(URI) as defined in [RFC3986], for designating connections and
destination addresses used in the Java(tm) Messaging Service (JMS)
[REF-JMS]. It was originally designed for particular uses, but
should have general applicability wherever a JMS URI is needed to
describe the connection to a JMS provider, and access to a JMS
destination. The syntax of this 'jms' URI is not compatible with any
known current vendor implementation, but the expressivity of the
format should permit all vendors to use it.
"Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi
Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar,
27-Aug-08, <draft-natarajan-tsvwg-sctp-nrsack-02.txt>
Stream Control Transmission Protocol (SCTP) [RFC4960] specifies
Selective Acknowledgements (SACKs) to allow a transport layer data
receiver to acknowledge DATA chunks which arrive out-of-order. In
SCTP, SACK information is advisory because the data receiver is
permitted to renege; that is, later discard a DATA chunk which
previously has been SACKed. Since delivery of a SACKed out-of-order
DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept
in the data sender's retransmission queue until this DATA chunk is
cumulatively acked.
This document specifies Non-Renegable Selective Acknowledgements (NR-
SACKs), an extension to SCTP's acknowledgment mechanism. NR-SACKs
enable a data receiver to explicitly acknowledge out-of-order DATA
chunks that have been delivered to the receiving application.
(Recall that, in SCTP, out-of-order data sometimes can be delivered.)
NR-SACKs also enable a data receiver to indicate any out-of-order
DATA chunks on which the receiver guarantees never to renege. As
opposed to SACKed DATA chunks, a sender can consider NR-SACKed DATA
chunks as never requiring retransmission, thus freeing space in the
data sender's retransmission queue sooner.
"Saratoga: A Scalable File Transfer Protocol", Lloyd Wood, Jim McKim, Wesley
Eddy, Will Ivancic, Chris Jackson, 31-Oct-08,
<draft-wood-tsvwg-saratoga-02.txt>
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 only 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.
"Instant Messaging Sessions within a Centralized Conferencing (XCON) System",
Chris Boulton, Mary Barnes, 30-Oct-08,
<draft-boulton-xcon-session-chat-02.txt>
The document "A Framework for Centralized Conferencing" defines a
centralized conference as both signaling and protocol agnostic. The
primary examples within this framework focus on audio and video as
the media types for the session. This document provides an overview
of the mechanisms defined in the centralized conferencing framework
that can be used to support Instant Messaging (IM) chat sessions. In
addition, the document describes additional functionality and
requirements necessary to provide feature rich chat functionality.
"Signaling Extensions for Wavelength Switched Optical Networks", Greg
Bernstein, 31-Oct-08, <draft-bernstein-ccamp-wson-signaling-03.txt>
This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched optical
networks (WSON). These extensions build on previous work for the
control of G.709 based networks.
"Mobility Support Using MPLS and MP-BGP Signaling", Oleg Berzin, Andrew
Malis, 29-Oct-08, <draft-berzin-malis-mpls-mobility-02.txt>
This document describes a new approach to handling user mobility at
the network layer in the context of Multi-Protocol Label Switched
Networks (MPLS). This approach does not rely on the existing IP
mobility management protocols such as Mobile IP, and is instead based
on the combination of Multi-Protocol BGP (MP-BGP) and MPLS. This
document proposes to introduce new protocol elements to MP-BGP to
achieve Mobility Label distribution at the network control plane and
the optimal packet delivery to the mobile node by the network
forwarding plane using MPLS.
"Routing and Wavelength Assignment Information Model for Wavelength Switched
Optical Networks", Young Lee, Dan Li, Wataru Imajuku, Greg Bernstein,
7-Jul-08, <draft-bernstein-ccamp-wson-info-03.txt>
This document provides an information model of information needed by
the routing and wavelength assignment (RWA) process in wavelength
switched optical networks (WSONs). The purpose of information
described in this model is to facilitate constrained lightpath
computation in WSONs. In particular in cases where there are no or a
limited number of wavelength converters available in the WSON. This
model currently does not include optical impairments.
"Distributed Universal Resource Name Resolution based on Distributed DNS",
Lican Huang, 4-Aug-08, <draft-licanhuang-dnsop-urnresolution-02.txt>
This file is a proposal for Universal Resource Name resolution based
on P2P DNS.
"Evaluation of Possible Interior Gateway Protocol Extensions for Wavelength
Switching Optical Networks", Dan Li, Jianhua Gao, Young Lee, Jianrui Han,
Baoquan Rao, Xinghua Shi, 12-Jul-08, <draft-li-ccamp-wson-igp-eval-01.txt>
Wavelength Division Multiplexing (WDM) is a technology for optical
communications, in which the user traffic is carried by data channels
of different optical wavelengths. In traditional WDM Networks, each
wavelength path is statically configured. With the deployment of the
Reconfigurable Optical Add-Drop Multiplexer (ROADM) and the
Wavelength Selective Switch (WSS), WDM networks have become more
dynamic, and operators can flexibly set up wavelength paths to carry
user traffic.
This document discusses the set of Interior Gateway Protocol (IGP)
requirements that would enable distributed light path computation in
Wavelength Switched Optical Networks (WSON). An IGP impact analysis
is also provided. According to the analysis, there is no significant
impact on the IGP performance.
"OCSP Algorithm Agility", Phillip Hallam-Baker, 2-Jul-08,
<draft-hallambaker-ocspagility-01.txt>
The behavior of an OCSP server is specified for cases in which the
OCSP server is capable of supporting more than one signature
algorithm.
"PCEP Requirements and Extensions for WSON Routing and Wavelength
Assignment", Young Lee, Greg Bernstein, 27-Oct-08,
<draft-lee-pce-wson-routing-wavelength-03.txt>
This memo provides application-specific requirements and protocol
enhancements for the Path Computation Element communication Protocol
(PCEP) for the support of Wavelength Switched Optical Networks
(WSON). Lightpath provisioning in WSONs requires a routing and
wavelength assignment (RWA) process. From a path computation
perspective, wavelength assignment is the process of determining
which wavelength can be used on each hop of a path and forms an
additional routing constraint to optical light path computation.
Different computational architectures for the RWA process are given
and the PCEP extensions needed to support these architectures are
defined.
"A lightweight security extension for the Unidirectional Lightweight
Encapsulation (ULE) protocol", Michael Noisternig, Bernhard Collini-Nocker,
14-Jul-08, <draft-noisternig-ipdvb-ulesec-01.txt>
The Unidirectional Lightweight Encapsulation (ULE) protocol is an
efficient and extensible transport mechanism for IP over MPEG-2
networks. Such networks are often operated on broadcast wireless
channels, and are thus specifically vulnerable to attacks. Passive
attacks, such as eaves-dropping, are simple to perform and emphasize
the importance of security support within ULE.
This document defines a mandatory security extension for the ULE
protocol that is designed with the aim of being conservative in
bandwidth consumption and lightweight in the sense that it allows for
implementation in low-cost, resource-scarce (mobile) receiver
devices. The extension may be easily adapted to the Generic Stream
Encapsulation (GSE) protocol, which uses the same extension header
mechanism. The document describes the format of the security
extension header, specifies default security algorithms to be used
with this extension, and gives detailed processing descriptions for
devices implementing the security extension.
Conventions used in this document
The following DVB specific terms are taken from [RFC4326] and
recapitulated here for easy lookup:
DVB: Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data using
the ISO MPEG-2 standard [MPEG2].
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG) and standardized by the International Standards
Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222].
NPA: Network Point of Attachment. In this document, refers to a 48-
bit destination address (resembling an IEEE MAC address) within the
MPEG-2 transmission network that is used to identify individual
receivers or groups of receivers.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PID: Packet Identifier [MPEG2]. A 13-bit field carried in the header
of TS cells. This is used to identify the TS Logical Channel to
which a TS cell belongs [MPEG2].
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
payload unit.
TS: Transport Stream [MPEG2]. A method of transmission at the MPEG-2
level using TS cells; it represents layer 2 of the ISO/OSI reference
model.
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level [MPEG2].
All packets sent over a TS Logical Channel carry the same PID value.
ULE: Unidirectional Lightweight Encapsulation [RFC4326]. A protocol
that encapsulates PDUs into SNDUs that are sent in a series of TS
cells using a single TS Logical Channel.
Terms and abbreviations from cryptography are explained when they
first appear within this document.
All numbers encoded in protocols are to be interpreted in network
byte order.
"Call on hold for telephony applications of SIP protocol", Daniele Giordano,
20-Aug-08, <draft-giordano-sip-call-hold-revision-01.txt>
Many RFCs and Internet Drafts describe call on hold methods adopted
in SIP signaling protocol. The actual implementation may not always
be ideal for telephony applications (reasons are explained below).
This draft proposes a revision of call on hold method for SIP
protocol.
Giordano
[page 1]
Internet-Draft Call on hold for telephony applications of SIP protocol
"Certificate profile and certificate management for SEND", Suresh Krishnan,
Ana Kukec, Khaja Ahmed, 3-Nov-08,
<draft-krishnan-cgaext-send-cert-eku-02.txt>
Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for
performing router authorization. This document specifies a
certificate profile for SEND including extended key usage values,
revocation details and supported extensions.
"Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco
Bonola, 6-Jun-08, <draft-krishnan-cgaext-proxy-send-01.txt>
Secure Neighbor Discovery (SEND) specifies a method for securing
Neighbor Discovery (ND) signaling against specific threats. As
specified today, SEND assumes that the node advertising an address is
the owner of the address and is in possession of the private key used
to generate the digital signature on the message. This means that
the Proxy ND signaling initiated by nodes that do not possess
knowledge of the address owner's private key cannot be secured using
SEND. This document extends the current SEND specification with
support for Proxy ND, the Secure Proxy ND Support for SEND.
"GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs,
Balazs Gero, Don Fedyk, Dinesh Mohan, 3-Nov-08,
<draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt>
The GMPLS controlled Ethernet Label Switching (GELS) work is
extending GMPLS RSVP-TE to support the establishment of Ethernet
LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an
adjunct OAM flow to check connectivity in Ethernet networks. CFM can
be also used with Ethernet LSPs for fault detection and triggering
recovery mechanisms. The ITU-T Y.1731 specification builds on CFM
and specifies additional OAM mechanisms, including Performance
Monitoring, for Ethernet networks. This document specifies
extensions of GMPLS RSVP-TE to support the setup of the associated
Ethernet OAM (CFM and Y.1731) entities adding a technology specific
TLV to [OAM-CONF-FWK].Changes from previous version
Technology independent extensions were moved to a separate framework
document leaving only the Ethernet specific extensions in this
document.
"Multiple Interfaced Mobile Nodes in NetLMM", Mohana Jeyatharan, Chan-Wah Ng,
Vijay Devarapalli, Jun Hirano, 30-Oct-08,
<draft-jeyatharan-netlmm-multi-interface-ps-03.txt>
The specific mechanism described in the current PMIPv6 draft to
support multihoming is such that a unique prefix is given to each
interface of a Mobile Node (MN) that is attached to the PMIPv6
domain. However, multihoming can also be provided using same unique
prefix for all interfaces of MN similar to the MONAMI6 (Mobile Nodes
and Multiple Interfaces in IPv6) concept. This memo explores and
highlights lack of advanced multihoming support and other hand-off
related issues where appropriate in three different mobility
management protocol models for multiple interfaced mobile nodes.
Firstly, when single prefix is allocated for all interfaces of MN in
the PMIPv6 domain. Secondly, when unique prefix is allocated for
each interface as in PMIPv6 standard protocol model. Thirdly, when a
multiple interfaced node uses different mobility management
mechanisms for each of its interfaces.
"OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi,
25-Sep-08, <draft-acee-ospf-transport-instance-01.txt>
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.
"Session Initiation Protocol Service Example -- Music on Hold", Dale Worley,
28-Aug-08, <draft-worley-service-example-02.txt>
The "music on hold" feature is one of the most desired features of
telephone systems in the business environment. "Music on hold" is
where, when one party to a call has the call "on hold", that party's
telephone provides an audio stream (often music) to be heard by the
other party. Architectural features of SIP make it difficult to
implement music-on-hold in a way that is fully compliant with the
standards. The implementation of music-on-hold described in this
document is fully effective and standards-compliant, but is simpler
than the methods previously documented.
"SMTP Service Extension for Indicating Message Authentication Status", Murray
Kucherawy, 29-Sep-08, <draft-kucherawy-sender-auth-esmtp-01.txt>
This memo defines an extension to the Simple Mail Transfer protocol
(SMTP) service whereby a server can indicate its ability to accept
and apply information regarding the efforts of upstream SMTP servers
to establish authenticity of the message via various authentication
methods.
"Problem Statement and Requirement: Mobile Multicast", Hui Deng, Peng Yang,
13-Jul-08, <draft-deng-multimob-ps-mobilemulticast-02.txt>
This document discusses the problem and requirement of multicast
solution in the mobile networks. One current issue in mobile
multicast solution has been raised and requirements of mobile IPTV on
multicast mobility will also be summarized especially for some
mechanisms such as the tunneling, service capability and security
discussion which is basis of supporting the mobile IPTV applications.
"Requirement for Multicast MPLS/BGP VPN Partitioning", Maria Napierala,
24-Jun-08, <draft-mnapierala-mvpn-part-reqt-02.txt>
This document describes a requirement for Multicast IP VPN solutions
to allow the same multicast stream to flow simultaneously on
multiple inter-PE paths without duplicates being sent to receivers.
It is intended that existing and new solutions to MPLS/BGP Multicast
IP VPN's will support this requirement.
"Load Balancing Fat MPLS Pseudowires", Stewart Bryant, Clarence Filsfils,
Ulrich Drafz, 9-Jul-08, <draft-bryant-filsfils-fat-pw-02.txt>
Where the payload carried over a pseudowire carries a number of
identifiable flows it can in some circumstances be desirable to carry
those flows over the equal cost multiple paths that exist in the
packet switched network. This draft describes a method of
identifying the flows, or flow groups, to the label switched routers
by including an additional label in the label stack.
"Flow Distribution Rule Language for Multi-Access Nodes", Conny Larsson,
Michael Eriksson, Koshiro Mitsuya, Kazuyuki Tasaka, Romain Kuntz, 14-Jul-08,
<draft-larsson-mext-flow-distribution-rules-01.txt>
This document defines an OS independent rule language as a mean to
define and perform per flow path selection for a multi-homed node.
Per flow path selection is typically needed when there exist multiple
network interfaces, each with different network characteristics, and
an application has specific performance requirements for a data flow
that makes one network interface more suitable than another.
The flow distribution rule set is used by the node itself but also
exchanged with other nodes that needs to know about the multi-homed
node's capability of receiving data on multiple network interfaces.
This document does not define how the rule set is transferred between
nodes.
"Media Control Channel Framework (CFW) Call Flow Examples", Alessandro
Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 3-Nov-08,
<draft-miniero-mediactrl-escs-03.txt>
This document provides with a list of more or less detailed Media
Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework]
call flows. It aims at being a simple guide throughout the use of
the interface between Application Servers and MEDIACTRL-based Media
Servers, as well as a hopefully helpful base reference documentation
for both implementors and protocol researchers.
"MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen,
IJsbrand Wijnands, 3-Jul-08, <draft-rosen-l3vpn-mvpn-profiles-01.txt>
The MVPN (Multicast Virtual Private Network) architecture is divided
into a number of functional "layers". At each layer, multiple
options are allowed. It is necessary to allow multiple options at
each layer because "one size doesn't fit all." However, it is not
expected that any particular implementation will support all the
possible combinations of options. To ensure multi-vendor
interoperability, it is useful to specify "profiles", where each
profile is a particular combination of options. The number of
specified profiles will be much less than the total number of
possible combination, and a given implementation can be characterized
by saying which profiles it supports. This document describes two
profiles that use a PIM control plane.
"Teredo Security Updates", Dave Thaler, Suresh Krishnan, James Hoagland,
14-Oct-08, <draft-krishnan-v6ops-teredo-update-04.txt>
The Teredo protocol defines a set of flags that are embedded in every
Teredo IPv6 address. This document specifies a set of security
updates that modify the use of this flags field, but are backward
compatible.
"End-Host Authentication for HIP Middleboxes", Tobias Heer, Klaus Wehrle,
Miika Komu, 7-Jul-08, <draft-heer-hip-middle-auth-01.txt>
The Host Identity Protocol [RFC2119]is a signaling protocol for
secure communication, mobility, and multihoming by introducing a
cryptographic namespace. This document specifies an extension for
HIP that enables middleboxes to unambiguously verify the identities
of hosts that communicate across them. This extension enables
middleboxes to verify the liveness and freshness of a HIP association
and, thus, enables reliable and secure access control in middleboxes.
"An HTTPS Location Dereferencing Protocol Using HELD", James Winterbottom,
Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson,
14-Jul-08, <draft-winterbottom-geopriv-deref-protocol-02.txt>
This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference into a Presence Information Data
Format Location Object (PIDF-LO). The document assumes that a
Location Recipient possesses a secure HELD URI that can be used in
conjunction with the HELD protocol to request the location of the
Target.
"Definitions of Managed Objects for the Fourth Version of Border Gateway
Protocol (BGP-4), BGP Community Extension", Jeffrey Haas, 2-Nov-08,
<draft-jhaas-idr-bgp4-mibv2-community-02.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing the Border Gateway Protocol's Community
extension.
"Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson,
James Winterbottom, 4-Jun-08, <draft-thomson-geopriv-uncertainty-01.txt>
The key concepts of uncertainty and confidence as they pertain to
location information are defined. A form for the representation of
confidence in Presence Information Data Format - Location Object
(PIDF-LO) is described, optionally including the form of the
uncertainty. Suggested methods for the manipulation of location
estimates that include uncertainty information are outlined.
"Automatic Generation of Site IDs for Virtual Private LAN Service", Bhupesh
Kothari, Kireeti Kompella, Thomas Spencer IV, 29-Oct-08,
<draft-kothari-l2vpn-auto-site-id-01.txt>
This document defines procedures that allow for Virtual Private LAN
Service (VPLS) provider edge (PE) devices that use BGP in the control
plane to automatically generate VE ID values in a consistent manner.
"Proxy Mutual Authentication in SIP", Steve Dotson, Stuart Hoggan, Sumanth
Channabasappa, 10-Jun-08, <draft-dotson-sip-mutual-auth-03.txt>
This document defines the Proxy-Authentication-Info header field for
the Session Initiation Protocol (SIP). When a UA is required to
authenticate to a proxy using digest authentication specified in SIP
this header field allows for the UA to authenticate the proxy,
enabling mutual authentication. This header field can also provide
integrity checks over the bodies.
"What Makes For a Successful Protocol?", Dave Thaler, Bernard Aboba,
27-May-08, <draft-iab-protocol-success-04.txt>
The Internet community has specified a large number of protocols to
date, and these protocols have achieved varying degrees of success.
Based on case studies, this document attempts to ascertain factors
that contribute to or hinder a protocol's success. It is hoped that
these observations can serve as guidance for future protocol work.
"Extension to the ua-profile Event Package to Support the Application Profile
Type", Martin Dolly, Sumanth Channabasappa, Joshua Littlefield, Salvatore
Loreto, 2-Nov-08, <draft-channabasappa-sipping-app-profile-type-03.txt>
The Framework for Session Initiation Protocol User Agent Profile
Delivery specifies an event package (ua-profile) that can be used by
user agents to retrieve profile data. The framework also allows for
optional notification of changes to the retrieved profiles. Three
profile types are specified: local-network, device, and user. This
document extends that event package to support an additional profile
type, application. This would enable User Agents to retrieve profile
data specific to one or more applications.
"DTLS-SRTP Key Transport", Dan Wing, 14-Jul-08,
<draft-wing-avt-dtls-srtp-key-transport-02.txt>
The existing DTLS-SRTP specification allows SRTP keys to be
established between a pair of SRTP endpoints. However, when there
are more than two participants in an RTP session, DTLS-SRTP is unable
to provide a single key for all of the participants. This existing
limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain
scenarios.
This document describes an extension to DTLS-SRTP, called Key
Transport (KTR). This extension transports SRTP keying material from
one DTLS-SRTP peer to another, so the same SRTP keying material can
be used by multiple DTLS-SRTP peers. This extension eliminates the
need to key each SRTP session individually, allowing cost-effective
deployment of several DTLS-SRTP scenarios.
"Multicast tunneling optimization for Mobile IPv6", Peng Yang, 14-Jul-08,
<draft-yang-multimob-mip6-mc-tunnel-opt-02.txt>
This document provides the solution to optimize the multicast
tunneling in mobile IPv6. This solution will not break the basic bi-
directional tunneling multicast solution of MIPv6. A new Mobile
Multicast Agent works as a proxy node for multiple mobile nodes
within one limit scope. Single tunnel is set up between one Home
Agent and one Mobile Multicast Agent for single multicast stream. A
new notification message is created for the communication between
home agent and mobile multicast agent. There is no modification on
mobile nodes.
"On Mobile IPv6 Optimization and Multihoming", Chan-Wah Ng, Keigo Aso,
8-Jul-08, <draft-ng-mobopts-multihoming-02.txt>
This memo explores the possible areas of extensions to MIPv6 route
optimization in the considerations of multihomed nodes. The
intention is to raise awareness in the research community, leading to
a possible extension to RFC 4651.
"Multiple Interface Support with Proxy Mobile IPv6", Vijay Devarapalli, Nishi
Kant, Heeseon Lim, Christian Vogt, 22-Aug-08,
<draft-devarapalli-netlmm-multihoming-03.txt>
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
mobile node with no mobility management protocol. It makes it appear
to the mobile node that its IP address does not change as the mobile
node moves across the Proxy Mobile IPv6 domain. There have been some
issues identified with supporting a host with multiple interfaces
attaching to the Proxy Mobile IPv6 domain. This document describes
and analyzes some of the scenarios associated with this.
"Using and Extending the NSIS Protocol Family", Jukka Manner, Roland Bless,
John Loughney, Elwyn Davies, 3-Nov-08, <draft-nsis-ext-02.txt>
This document gives an overview of the Next Steps in Signaling (NSIS)
framework and protocol suite created by the NSIS working group during
the period 2001-2008 together with suggestions on how the industry
can make use of the new protocols, and how the community can exploit
the extensibility of both the framework and existing protocols to
address future signaling needs.
"Multi-homing in BGP-based Virtual Private LAN Service", Kireeti Kompella,
Bhupesh Kothari, Thomas Spencer IV, 3-Nov-08,
<draft-kompella-l2vpn-vpls-multihoming-02.txt>
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo
shows how multi-homing can be offered in the context of BGP-based
VPLS.
"Definition of Master Key between PANA Client and Enforcement Point",
Yoshihiro Ohba, 24-Oct-08, <draft-ohba-pana-pemk-02.txt>
This document defines a master key used between a client of the
Protocol for carrying Authentication for Network Access (PANA) and an
enforcement point, for bootstrapping lower-layer ciphering. The
master key is derived from the Master Session Key of Extensible
Authentication Protocol as a result of successful PANA
authentication. The master key guarantees cryptographic independence
among enforcement points across different types of lower-layers.
"Performance Evaluation of PCN-Based Algorithms", Michael Menth, Frank
Lehrieder, 4-Jul-08, <draft-menth-pcn-performance-03.txt>
This document presents a summary of performance studies for PCN-based
admission control and flow termination. The numerical results were
obtained by simulation or mathematical analysis.
"Ad-Hoc IP Autoconfiguration Solution Space Analysis", Carlos Bernardos,
Maria Calderon, Hassnaa Moustafa, 1-Nov-08,
<draft-bernardos-autoconf-solution-space-02.txt>
This draft aims at analysing the solution space for the ad hoc IP
autoconfiguration problem, based on the problem statement draft and
the MANET architecture draft. Some evaluation considerations, are
also taken into account. This draft classifies, at a generic level,
the solution space of the possible approaches that could be followed
to solve the IPv6 autoconfiguration for MANETs problem. The various
approaches of IPv6 autoconfiguration for MANETs are illustrated, and
the benefits and tradeoffs in different aspects of IPv6
autoconfiguration are explored.
"Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless Mesh
Network scenarios", Carlos Bernardos, Maria Calderon, Ignacio Soto, 2-Nov-08,
<draft-bernardos-autoconf-backbone-mesh-reqs-01.txt>
This Internet Draft presents the multi-hop Backbone Wireless Mesh
Network scenario, summarising its basic characteristics and
describing the requirements and desired properties of an IP
Autoconfiguration mechanism aimed at being used in this kind of
networks.
Once that the AUTOCONF WG has almost finalised the documents that
describe the general architecture of MANETs and the IP
autoconfiguration problem statement in MANETs, the WG is expected to
start working on solutions. This document describes an ad-hoc
scenario that is getting a lot of attention from both
telecommunication operators and end-users: Backbone/infrastructure
Wireless Mesh Networking. This document identifies and explains the
requirements posed by this particular scenario to an IP
autoconfiguration mechanism. The goal is to help the AUTOCONF WG
identify the requirements that need to be taken into account when
designing IP autoconfiguration solution(s) suitable for this Wireless
Mesh environment.
"IANA Registration for Encrypted ENUM", Ben Timms, Jim Reid, Jakob Schlyter,
12-Jul-08, <draft-timms-encrypt-naptr-01.txt>
This document requests IANA registration of the "X-Crypto"
Enumservice. This Enumservice indicates that its NAPTR holds a
Uniform Resource Identifier that carries encrypted content from the
fields of another (unpublished) Protected NAPTR, for use in E.164
Number Mapping (ENUM).
"Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 11-Aug-08,
<draft-oiwa-http-mutualauth-03.txt,.ps,.pdf>
This document specifies the "Mutual authentication protocol for
Hyper-Text Transport Protocol". This protocol provides true mutual
authentication between HTTP clients and servers using simple
password-based authentication. Unlike Basic and Digest HTTP access
authentication protocol, the protocol ensures that server knows the
user's entity (encrypted password) upon successful authentication.
This prevents common phishing attacks: phishing attackers cannot
convince users that the user has been authenticated to the genuine
website. Furthermore, even when a user has been authenticated
against an illegitimate server, the server cannot gain any bit of
information about user's passwords. The protocol is designed as an
extension to the HTTP protocol, and the protocol design intends to
replace existing authentication mechanism such as Basic/Digest access
authentications and form-based authentications.
"IGMP/MLD Error Feedback", Thomas Morin, Brian Haberman, 3-Nov-08,
<draft-morin-mboned-igmpmld-error-feedback-02.txt>
This document describes messages and procedures that can optionally
be implemented in IGMP/MLD Queriers and Hosts, to provide information
to multicast receivers on the reason why the IGMP/MLD Querier didn't
take into account a Membership Report message.
"The Zone Status (ZS) DNS Resource Record", Jim Reid, 4-Jul-08,
<draft-reid-dnsext-zs-01.txt>
A Domain Name System (DNS) resource record which provides status
information about a zone is described in this document.
"Rogue IPv6 Router Advertisement Problem Statement", Tim Chown, Stig Venaas,
3-Nov-08, <draft-chown-v6ops-rogue-ra-02.txt>
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.
However, unintended misconfigurations 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. The goal of
this text is to be Informational, and as such to present a framework
around which solutions can be proposed and discussed.
"Mediator-Specific Extensions to IPFIX Protocol and Information Model",
Christoph Sommer, Falko Dressler, Gerhard Muenz, 14-Jul-08,
<draft-sommer-ipfix-mediator-ext-01.txt>
IPFIX supports the concept of a Mediator, a device that receives,
transforms, and exports data streams using IPFIX. One of the most
important requirements is the reduction of the volume of IPFIX
traffic by aggregating and discarding received information. This
document introduces a number of extensions to the IPFIX Information
Model that support the export of aggregated IPFIX data, introducing
abstract data types and Information Elements that optimize the
transport of descriptive information in terms of flow records' amount
and size. All extensions are directly applicable to the IPFIX
Mediator but can be used in many different applications as well.
"MPLS and Ethernet OAM Interworking", Dinesh Mohan, Nabil Bitar, Simon
Delord, Philippe Niger, 8-Jul-08, <draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt>
This document specifies the mapping of defect states between
Ethernet Attachment Circuits (ACs) and associated Ethernet
Pseudowires (PWs) connected in accordance to the PWE3 architecture
[RFC3985] to realize an end-to-end emulated Ethernet service. This
document augments the mapping of defect states between a PW and
associated AC of the end-to-end emulated service in [PW-OAM-MSG-
MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack
of Ethernet OAM maturity. However, since then, [Y.1731] and[802.1ag] have
been completed, and this document specifies the mapping of defect states
between Ethernet ACs and corresponding Ethernet PWs.
"Problem Statement: Transport Protocols Don't Have To Do Fairness", Bob
Briscoe, T Moncaster, Anne-Louise Burness, 14-Jul-08,
<draft-briscoe-tsvwg-relax-fairness-01.txt>
The Internet is an amazing achievement - any of the thousand million
hosts can freely use any of the resources anywhere on the public
network. At least that was the original theory. Recently issues
with how these resources are shared among these hosts have come to
the fore. Applications are innocently exploring the limits of
protocol design to get larger shares of available bandwidth.
Increasingly we are seeing ISPs imposing restrictions on heavier
usage in order to try to preserve the level of service they can offer
to lighter customers. We believe that these are symptoms of an
underlying problem: fair resource sharing is an issue that can only
be resolved at run-time, but for years attempts have been made to
solve it at design time. In this document we show that fairness is
not the preserve of transport protocols, rather the design of such
protocols should be such that fairness can be controlled between
users and ISPs at run-time.
"Network Scaling with Aggregate LSPs", George Swallow, Jim Guichard,
Intellectual Property, 7-Jul-08, <draft-swallow-mpls-aggregate-fec-01.txt>
This document defines a means for an Multiprotocol Label Switched
network to summarize routes while maintaining end-to-end LSP
connectivity thereby reducing the number of host routes that need
to be carried within the interior gateway protocol.Contents
"LISP Alternative Topology (LISP+ALT)", Vince Fuller, Dave Meyer, Dino
Farinacci, 22-Oct-08, <draft-fuller-lisp-alt-03.txt>
This document describes a method of building an alternative, logical
topology for managing Endpoint Identifier to Routing Locator mappings
using the Locator/ID Separation Protocol. The logical network is
built as an overlay on the public Internet using existing
technologies and tools, specifically the Border Gateway Protocol and
the Generic Routing Encapsulation. An important design goal for
LISP+ALT is to allow for the relatively easy deployment of an
efficient mapping system while minimizing changes to existing
hardware and software.
"Point-to-Multipoint Pseudowire Signaling and Auto-Discovery in Layer 2
VPNs", Rahul Aggarwal, 13-Jul-08, <draft-raggarwa-l2vpn-p2mp-pw-01.txt>
A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that
emulates the essential attributes of a unidirectional P2MP
Telecommunications service such as P2MP ATM over a Packet Switched
Network (PSN). [RFC4664] describes a number of different ways in
which sets of PWs may be combined together into "Provider Provisioned
Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of
different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a
Virtual Private P2MP unidirectional service (VPMS), which may be in
addition to the Virtual Private Wire Service (VPWS) offered by the
L2VPN.
This document describes how procedures outlined in [VPLS-MCAST] can
be used to signal P2MP PWs and enable a P2MP unidirectional service
in a L2VPN.
"VPLS OAM", Dinesh Mohan, Ali Sajassi, Deborah Brungard, Henry Fowler, Simon
Delord, Philippe Niger, 12-Jul-08, <draft-mohan-l2vpn-vpls-oam-01.txt>
This document provides a comprehensive end-to-end solution for VPLS
Operation, Administration and Maintenance (OAM). This solution is
based on the L2VPN OAM framework [L2VPN-OAM-REQ-FRMK] and specifies
how to meet the requirements set therein.
"BGP protocol extensions using attribute for Path Computation Element (PCE)
Discovery in a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 28-Oct-08,
<draft-kumaki-pce-bgp-disco-attribute-02.txt>
It is highly desirable for Path Computation Clients (PCCs) to be
able to dynamically discover a set of Path Computation Elements
(PCEs) when PCCs/PCEs request a path computation to PCEs within an
AS and across ASs. In such a scenario, specifically BGP/MPLS IP-VPNs,
it is advantageous to use BGP to distribute PCE information. This document
defines a new attribute and describes how PCE information can be carried
using BGP.
"RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 21-Aug-08,
<draft-wang-avt-rtp-mvc-02.txt>
This memo describes an RTP payload format for the multiview
extension of the ITU-T Recommendation H.264 video codec that is
technically identical to ISO/IEC International Standard 14496-10.
The RTP payload format allows for packetization of one or more
Network Abstraction Layer (NAL) units, produced by the video
encoder, in each RTP payload. The payload format has wide
applicability, such as 3D video streaming, free-viewpoint video, and
3DTV.
"Mobile Multicast Requirements on IGMP/MLD Protocols", Hui Liu, Hitoshi
Asaeda, 13-Oct-08, <draft-liu-multimob-igmp-mld-mobility-req-01.txt>
This document presents the requirements for IGMP/MLD protocols to
allow the deployment of mobile multicast service. It is intended to
provide useful guideline when adapting current IGMP/MLD protocols to
support terminal mobility.
"IGMP and MLD Extensions for Mobile Hosts and Routers", Hitoshi Asaeda,
Thomas Schmidt, 14-Jul-08,
<draft-asaeda-multimob-igmp-mld-mobility-extensions-01.txt>
This document describes IGMP and MLD protocol extensions for mobile
hosts and routers. IGMP and MLD are necessary protocols for hosts to
request join or leave multicast sessions. While the regular IGMP and
MLD protocols support communication between mobile hosts and routers
over wireless networks, this document discusses the conditions how
mobile hosts and routers use IGMP and MLD in their communication more
effectively. Aside from a modified protocol semantic, an optional
"Listener Hold" function for the IGMP and MLD protocol is introduced,
which requires an extended signaling.
"Camellia Counter mode and Camellia Counter with CBC Mac mode algorithms",
Akihiro Kato, Masayuki Kanda, 16-Sep-08, <draft-kato-camellia-ctrccm-04.txt>
This document describes the algorithms and test vectors of Camellia
block cipher algorithm in Counter mode and Counter with Cipher Block
Chaining MAC mode. The purpose of this document is to make the
Camellia-CTR and Camellia-CCM algorithm conveniently available to the
Internet Community.
"A Session Description Protocol (SDP) Control Package Attribute", Chris
Boulton, 20-Aug-08,
<draft-boulton-mmusic-sdp-control-package-attribute-03.txt>
This document defines a new Session Description Protocol (SDP) media-
level attribute: "ctrl-package". The "ctrl-package" attribute
conveys details of the SIP Control Framework extension packages that
are supported by a client participating in an offer/answer exchange.
"RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang,
7-Oct-08, <draft-lakaniemi-avt-rtp-evbr-04.txt>
This document specifies the Real-Time Transport Protocol (RTP)
payload format for the Embedded Variable Bit-Rate (EV-VBR)
speech/audio codec, specified in ITU-T G.718. A media type
registration for this RTP payload format is also included.
"Providing guidance for Session Initiation Protocol (SIP) services", Arnaud
Ligot, Thomas Froment, 11-Jul-08,
<draft-ligot-bliss-sip-services-guide-02.txt>
Implementing Session Initiation Protocol (SIP) advanced features and
services requires to use numerous specifications. Today, for each
service in the scope of BLISS, one can already find references to
many possible specifications which do not cover the same things.
Some of them are primitive operations, requirements or call flow
examples, some have a scope larger than the others, or can not be
compared at the same level. Very often, architecture hypothesis are
hidden behind the same service name, either assuming that an
intermediary; like an application server, has an active role in the
service, or, as opposed, assuming a pure end-to-end model where only
endpoint implementations are involved. The goal of this document is
not to present the best solutions or give recommendations; but to
give an overview of every standard specification related to these
services, centralizing and categorizing them as input to the working
group.
"Service Identfiers Option for DHCPv6", Hui Deng, Hong Liu, Bernie Volz,
3-Nov-08, <draft-deng-dhc-service-identifiers-03.txt>
This document describes a new option for DHCPv6 [RFC3315] that
provides a mechanism for specifying a list of service identifer which
this connection support or don't support.
"Verification of Care-of Addresses in Multiple Bindings Registration",
Benjamin Lim, Chan-Wah Ng, Keigo Aso, Suresh Krishnan, 10-Jul-08,
<draft-lim-mext-multiple-coa-verify-02.txt>
Using multiple care-of address registration, there is a possibility
that a malicious mobile node could create multiple care-of address
bindings that does not belong to the mobile node at its home agent.
The home agent would accept these bindings without verifying them due
to the trust relationship it has with the mobile node. With these
bindings, the mobile node can launch attacks by asking the home agent
to flood the victims of these care-of addresses with useless packets.
To mitigate such a problem, this memo introduces a few possible
verification mechanisms that the home agent would use in order to
verify the care-of addresses for the mobile node before using them
for packet routing.
"An Explicit Signaling Target Message Routing Method (EST-MRM) for the
General Internet Signaling Transport (GIST) Protocol", Roland Bless,
8-Jul-08, <draft-bless-nsis-est-mrm-01.txt>
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) in order to allow sending of signaling messages to
explicit targets.
"Reporting of DKIM Verification Failures", Murray Kucherawy, 10-Jul-08,
<draft-kucherawy-dkim-reporting-04.txt>
This memo presents an extension to the DomainKeys Identified Mail
(DKIM) specifications to allow public keys for verification to
include a reporting address to be used to report message verification
issues, and extends an Internet Message reporting format to be
followed when generating such reports.
"Roaming Mechanism between PMIPv6 Domains", Jee-Hyeon Na, Soochang Park,
Jung-Mo Moon, Sangho Lee, Euisin Lee, Sang-Ha Kim, 10-Jul-08,
<draft-park-netlmm-pmipv6-roaming-01.txt>
Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to
mobile nodes in the network domain which does not require the mobile
nodes to be involved in IP mobility management. In other words, the
PMIPv6 can transparently support roaming within a PMIPv6 domain, i.e.
intra-domain roaming, to mobile nodes. However, if the mobile nodes
move to other PMIPv6 domains, the nodes should have additional
protocols for the inter-domain roaming although the domains also
provide the transparent mobility. Hence, an inter-domain roaming
solution would be needed for providing transparent mobility to mobile
nodes that only move around among PMIPv6 domains. This document
specifies the inter-domain roaming controlled by the networks
adopting the PMIPv6.
"DHCP Segmentation/Reassembly using SEAL", Fred Templin, 30-Jul-08,
<draft-templin-dhcpmtu-01.txt>
IP fragmentation has been shown to be problematic through operational
experience and through studies conducted over the course of many
years. Some transports (e.g., TCP) have the abilitiy to adjust their
message sizes to avoid IP fragmentation, however no such capability
is built into the UDP transport. UDP applications such as DHCP must
therefore have a means to perform their own segmentation prior to
submitting their data to UDP/IP in order to avoid IP fragmentation.
This document specifies a segmentation/reassembly capability for DHCP
using SEAL.
"An overload control package for the Session Initiation Protocol (SIP).",
Youssef Chadli, Xavier Marjou, 11-Jul-08,
<draft-chadli-sipping-overload-sub-not-01.txt>
This document specifies an event package for the notification of
overload control using the Session Initiation Protocol (SIP) events
framework. The overload control package allows an upstream server to
retrieve overload control information from a downstream server and to
be notified when this information changes. This information is used
by the upstream server to adapt its flow toward the downstream server
and thus to avoid overloading it.
"UDP Traceroute Message Extension", Naiming Shen, Carlos Pignataro, Rajiv
Asati, Enke Chen, 7-Jun-08, <draft-shen-udp-traceroute-ext-01.txt>
This document specifies an extension to UDP traceroute messages that
allows the UDP traceroute 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 sender is
interested to receive from one or more nodes via the traceroute
replies.
"Proactive Bindings for FMIPv6", Faqir Yousaf, Christian Wietfeld, 14-Jul-08,
<draft-yousaf-ietf-mipshop-pbfmipv6-01.txt>
Usually in FMIPv6, the MN will start the binding process with its
home agent and the correspondent nodes after it has attached to NAR.
Till the binding is completed, the mobile node continues to receive
packets via a reverse tunnel established between PAR and NAR. The
duration of this tunnel will depend on the time it takes for the
mobile node to complete its binding, till which time the tunnel will
continue to consume buffer and processing resources related to
maintaining the tunnel and forwarding packets through this tunnel in
both PAR and NAR.
This document specifies an extension to FMIPv6 to enhance its
performance, in terms of resource management, by reducing the
duration of the tunnel existence. This is achieved by enabling the
NAR to act as a proxy for the MN for FMIPv6 handover. Additional
message(s) and message options along with modifications to existing
FMIPv6 messages and message options and definitions of new messages
and message options to achieve the desired functionality is also
described in this document.
"Diagnose P2PSIP Overlay Network Failures", Song Yongchao, Hewen Zhang,
XingFeng Jiang, 3-Nov-08, <draft-zheng-p2psip-diagnose-03.txt>
This document describes P2PSIP diagnostics. It extends the methods
defined in the base protocol for the diagnostics in P2PSIP overlay
network. A new method Echo is an efficient method used in the trusted
overlays for retrieving useful diagnostic information. The methods
and message formats are consistent with P2PSIP base protocol RELOAD,
and the diagnostic information mainly comes from the previous
version-02 of this document.
"Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino
Farinacci, Vince Fuller, 11-Jul-08, <draft-lewis-lisp-interworking-01.txt>
This document describes techniques for allowing sites running the
Locator/ID Separation Protocol (LISP [LISP]) to interoperate with
Internet sites 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 IP addresses, routes for 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 two such mechanisms: the first uses a new
network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to
act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-
speaking hosts while the second adds Network Address Translation
(NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers
(xTRs) to substitute routable IP addresses for non-routable EIDs.
"Clearance Attribute and Authority Clearance Constraints Certificate
Extension", Sean Turner, Santosh Chokhani, 1-Nov-08,
<draft-turner-caclearanceconstraints-02.txt>
This document defines the syntax and semantics for the Clearance
attribute and the Authority Clearance Constraints extension in X.509
certificates. The Clearance attribute is used to indicate the
clearance held by the subject. The Clearance attribute may appear in
the subject directory attributes extension of a public key certificate or
in the attributes field of an attribute certificate. The Authority Clearance
Constraints certificate extension values in a Trust Anchor (TA), CA public
key certificates, and an Attribute Authority (AA) public key certificate
in a public key certification path constrain the effective Clearance of the
subject.
"Specifying Location Quality Constraints in Location Protocols", Martin
Thomson, James Winterbottom, 26-May-08,
<draft-thomson-geopriv-location-quality-01.txt>
Parameters that define the expected quality of location information
are defined for use in location protocols. These parameter can be
used by a requester to indicate to a Location Server the desired
constraints on the quality of the location information provided. If
applicable, the Location Server is able to use this information to
control how location information is determined. An optional
indication of whether the quality constraints were met is defined to
be provided by the Location Server alongside location information.
"Other Certificates Extension", Stephen Farrell, 8-Jul-08,
<draft-farrell-pkix-other-certs-03.txt>
Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information. This memo defines a certificate
extension that supports such linkage that can allow applications to
establish the required linkage without introducing a new application
protocol data unit.
"Retriving MIB Information based on NGI", JinXiang Zhang, 8-Oct-08,
<draft-jinxiang-operations-and-management-ngi-01.txt>
An important task of network management is to collect and analyze
MIB information of various object combinations based on the
Simple Network Management Protocol (SNMP) with proper frequency.
The purpose of this document is to propose two algorithms to retrieve
MIB information for a large (up to exponential) number of managed
objects using SNMP in Next Generation Internet (NGI).
"L2TPv3 Extended Circuit Status Values", Neil McGill, Carlos Pignataro,
25-Jun-08, <draft-nmcgill-l2tpext-circuit-status-extensions-01.txt>
This document defines additional Layer 2 Tunneling Protocol Version 3
(L2TPv3) bit values to be used within the "Circuit Status" Attribute
Value Pair (AVP) to communicate more granular error states for Access
Circuits and Pseudowires. It also deprecates the use of the New bit
in the "Circuit Status" AVP, updating RFC3931.
"XESP for Traffic Visibility", Ken Grewal, 23-Jun-08,
<draft-grewal-ipsec-traffic-visibility-01.txt>
This document describes an ESP encapsulation for IPsec, allowing
intermediate devices to ascertain if ESP-NULL is being employed and
hence inspect the IPsec packets for network monitoring and access
control functions. Currently in the IPsec standard, there is no way
to differentiate between ESP encryption and ESP NULL encryption by
simply examining a packet.
"Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Presence", Peter
Saint-Andre, Avshalom Houri, Joe Hildebrand, 5-Aug-08,
<draft-saintandre-sip-xmpp-presence-01.txt>
This document defines a bi-directional protocol mapping for the
exchange of presence information between the Session Initiation
Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP).
"Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat",
Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 10-Jul-08,
<draft-saintandre-sip-xmpp-chat-02.txt>
This document defines a bi-directional protocol mapping for the
exchange of instant messages in the context of a one-to-one chat
session between a user of the Session Initiation Protocol (SIP) and a
user of the Extensible Messaging and Presence Protocol (XMPP).
Specifically for SIP text chat, this document specifies a mapping to
the Message Session Relay Protocol (MSRP).
"On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship",
Wassim Haddad, Mats Naslund, 13-Jul-08,
<draft-haddad-cgaext-symbiotic-sendproxy-01.txt>
This document introduces a simple mechanism which enables a host
using IPv6 cryptographically generated address to delegate the task
of secure neighbor discovery proxying to another node by means of
establishing a "symbiotic" relationship with that node.
"On Using 'Symbiotic Relationship' to Repel Network Flooding Attack", Wassim
Haddad, Mats Naslund, 26-Oct-08,
<draft-haddad-mipshop-netflood-defense-02.txt>
This memo describes a simple defense mechanism against a specific
type of network flooding attacks. The suggested mechanism requires a
mobile node to establish a 'symbiotic relationship' with the
infrastructure, in order to empower it to repel such attack while
giving enough insurance to the source(s) of the traffic about the
need to cease sending traffic to the targeted network.
"Syntax for binding documents with time stamps", Adriano Santoni, 10-Jun-08,
<draft-santoni-timestampeddata-04.txt>
This document describes a syntax which can be used to bind a generic
document (or any set of data, not necessarily protected by means of
cryptographic techniques) to one or more time-stamp tokens obtained
for that document, where "time-stamp token" has the meaning defined
in RFC 3161. Additional types of temporal evidence are also
supported.
Santoni
Expires December 10, 2008
[page 1]
Internet-Draft
timestampeddata
June 2008
This document proposes a simple syntax based on the Cryptographic
Message Syntax (RFC 3852).
"LDP extension for AII reachability", Luca Martini, Philippe Niger, Yaakov
Stein, Frederic JOUNAY, Matthew Bocci, Simon DeLord, 22-Sep-08,
<draft-delord-jounay-pwe3-ldp-aii-reachability-02.txt>
The dynamic End-to-End Multisegment pseudowire setup requires PEs to
maintain a pseudowire routing table when using FEC129. There is a
requirement to automatically advertise Attachment Individual
Identifiers to enable the pseudowire routing tables to be populated.
Two mechanisms already exist, a BGP reachability information
distribution mechanism and an IGP based one. Here we define a third
solution relying on LDP. It allows for automatic advertisement of the
Attachment Individual Identifier prefixes provisioned on a T-PE when
this node does not run BGP or IGP. The mechanism described here runs
on the T-LDP (Targeted LDP) session between the T-PE and S-PE, and
is intended to complement existing PW routing mechanisms using BGP or
OSPF.
"Extensible Supply-chain Discovery Service Problem Statement", , 17-Nov-08,
<draft-rezafard-esds-problem-statement-03.txt>
This document discusses the requirements of an application layer
protocol for Discovery Services. Discovery Services at its core
offers to authenticated and authorized users the means to discover
resources of information for a particular identifier. The
information resource can be any data source which provides an
interface on a network that allows for retrieval of the data. An
information resource could publish its network address (reference to
the resource) to a Discovery Service coupled with an identifier.
Then an authenticated and authorized user could query the Discovery
Service with the same identifier to receive reference information to
the resources. Interfacing with the resources for actually
retrieving the data is out of scope of Discovery Services; the role
of Discovery Services is to enable a client to find the network
addresses and types (e.g. URLs) of information resources for a
particular identifier of interest.
This protocol is applicable to numerous scenarios such as track and
trace in trade supply chains, where a number of independent resources
may hold information about a particular object and may have an
interest in selective sharing of that information, in order to
improve the efficiency of the supply chain network.
However, other applications can be envisaged, as a 'bottom-up' or
'grassroots' way for generators of information content to: 1) declare
that they have information or commentary on a particular topic or
subject (which might be a physical object, geographic location or
even an abstract concept) 2) specify a network address through which
that content can be retrieved, 3) specify restrictions about the
community of clients that are entitled to receive knowledge about the
existence of their content or see the link. This approach can be
contrasted with the top-down approach of existing web search engines
that rely on crawling/spidering of content that must be already
posted in the public domain before it can be indexed - and where the
link information is generally made publicly available in a manner
that does not discriminate between clients on an individual basis.
This document outlines a set of design concerns that an application
layer protocol needs to address in order to be widely adopted and
deployable on public networks
This document obsoletes "Extensible Supply-chain Discovery Service
Problem Statement draft-rezafard-esds-problem-statement-02".
Comments are solicited and should be addressed to the mailing list at
esds@ietf.org and/or the author(s).
"The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force",
Paul Hoffman, 2-Nov-08, <draft-hoffman-tao4677bis-04.txt>
This document describes the inner workings of IETF meetings and
Working Groups, discusses organizations related to the IETF, and
introduces the standards process. It is not a formal IETF process
document but instead an informational overview.
"Digital Signatures on Internet-Draft Documents", Russ Housley, 21-Aug-08,
<draft-housley-internet-draft-sig-file-06.txt>
This document specifies the conventions for digital signatures on
Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to
create a detached signature, which is stored in a separate companion
file so that no existing utilities are impacted by the addition of
the digital signature.
"Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging
and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)",
Salvatore Loreto, 14-Jul-08, <draft-loreto-simple-im-srv-label-02.txt>
This document registers with IANA two new DNS SRV Protocol Labels for
resolving Instant Messaging and Presence services with SIP.
"Connecting IPv6 Islands over IPv4 MPLS networks using IPv6 Provider Edge
Routers (6PE-Alt)", Vishwas Manral, 4-Sep-08,
<draft-manral-idr-mpls-explicit-null-01.txt>
This document provides an alternate mechanism to [6PE] to interconnect
IPv6 routes over MPLS-enabled IPv4clouds. This approach
relies on IPv6 Provider Edge routers (6PE-Alt) which are Dual Stack in
order to connect to IPv6 islands and to the MPLS core which is only
required to run IPv4 MPLS and run the mechanism as described in this
document. The 6PE-Alt routers exchange the IPv6 reachability
information transparently over the core using the Multi-Protocol
Border Gateway Protocol (MP-BGP) over IPv4 or IPv6. In doing so,
the BGP Next Hop field is used to convey the IPv4 address of the 6PE-Alt
router so that dynamically established IPv4-signaled MPLS Label
Switched Paths (LSPs) can be used without explicit tunnel
configuration. Unlike [6PE] case the labels are not sent with each route
and does not use BGP to transport labels [RFC3107]. It instead makes use
of the IPv6 Explicit NULL label as the VPN label, which is defined
[RFC3032] and updated in [RFC4182].
This document elegantly uses the concept of non overlapping IPv6 routes to
provide BGP MPLS IP VPN functionality. The document can be further used for
provinding the functionality in case of non-overlapping IPv6 routes.
This approach allows a functionality similar to [RFC4659], without the
cumbursome extensions required for the same. With the [RFC3879] IPv6 addresses
are now globally unique (except for Link local). It also reduces the number
of multi AS scenarios.
"Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos
Mavrogiannopoulos, 26-Oct-08, <draft-mavrogiannopoulos-rfc5081bis-02.txt>
This memo proposes extensions to the Transport Layer Security (TLS)
protocol to support the OpenPGP key format. The extensions discussed
here include a certificate type negotiation mechanism, and the
required modifications to the TLS Handshake Protocol.
"sNAT-PT: Simplified Network Address Translation - Protocol Translation",
Hiroshi Miyata, Masahito Endo, 29-Sep-08, <draft-miyata-v6ops-snatpt-02.txt>
This document specifies an IPv4-to-IPv6 transition mechanism to
provide accessibility for IPv6 node to IPv4 node, and vice-versa.
The goal of this document is not providing the most fundamental
technology which could works well with additional technology.
We used to have an technology called NAT-PT[RFC2766]. NAT-PT was
designed to work with problematic DNS Application Level Gateway. So,
it was changed to historical state by [RFC4966].
This document attempts to simplify NAT-PT specification, removing
dependability on Application Layer Gateway as well as resolving
problems pointed in [RFC4966].
"Shim6 Implementation Report : LinShim6", Sebastien Barre, 11-Jul-08,
<draft-barre-shim6-impl-01.txt,.ps,.pdf>
LinShim6 is an implementation of the Shim6 and REAP protocols, on the
Linux platform. This draft provides a description of the
architecture and describes the current state of our implementation.
The level of support of each protocol feature is detailed. Protocol
conformance is evaluated against the main drafts.
"Special Use IPv4 Addresses", Michelle Cotton, 2-Jun-08,
<draft-iana-rfc3330bis-03.txt>
This document obsoletes RFC 3330. It describes the global and other
specialized IPv4 address blocks that have been assigned by the
Internet Assigned Numbers Authority (IANA). It does not address IPv4
address space assigned to operators and users through the Regional
Internet Registries. It also does not address allocations or
assignments of IPv6 addresses or autonomous system numbers. Special
IPv6 addresses are described in RFC 5156.
"Indicating Support for Basic Media Server Capabilities in the Session
Initiation Protocol (SIP)", Chris Boulton, 20-Aug-08,
<draft-boulton-mediactrl-feature-tags-01.txt>
This specification defines a profile set of media feature tags that
can be used with the Session Initiation Protocol (SIP). The media
feature tags allow a Media Server to communicate a basic set of media
server capabilities that are supported to its Application Server.
"EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn,
19-Nov-08, <draft-harkins-emu-eap-pwd-03.txt>
This memo describes an Extensible Authentication Protocol (EAP)
method, EAP-pwd, which uses a shared password for authentication.
The password may be a low-entropy one and may be drawn from some set
of possible passwords, like a dictionary, which is available to an
attacker.
"IMAP Response Codes", Arnt Gulbrandsen, 27-Oct-08,
<draft-gulbrandsen-imap-response-codes-04.txt>
IMAP responses consist of a response type (OK, NO, BAD), an optional
machine-readable response code and a human-readable text.
This document collects and documents a variety of machine-readable
response codes, for better interoperation and error reporting.1. Conventions
Used in This Document
Formal syntax is defined by [RFC5234] as modified by [RFC3501].
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. "[...]" means elision.
"Probabilistic Routing Protocol for Intermittently Connected Networks",
Anders Lindgren, Avri Doria, 17-Nov-08, <draft-irtf-dtnrg-prophet-01.txt>
This document defines PRoPHET, a Probabilistic Routing Protocol using
History of Encounters and Transitivity. PRoPHET is a routing
protocol for intermittently connected networks, where there is no
guarantee that a fully connected path between source and destination
exists at any time, rendering traditional routing protocols unable to
deliver messages between hosts. These networks are examples of
networks where the Delay-Tolerant Network architecture[1] is
applicable. The document presents an architectural overview followed
by the protocol specification.
"The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin,
19-Aug-08, <draft-templin-seal-23.txt>
For the purpose of this document, subnetworks are defined as virtual
topologies that span connected network regions bounded by
encapsulated border nodes. These virtual topologies 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.
"XCAST6 (version 2.0) Protocol Specification", Yuji Imai, Takahiro Kurosawa,
Nobuo Kawaguchi, Eiichi Muramoto, 17-Aug-08,
<draft-ug-xcast20-protocol-spec-01.txt>
This document describes the specification of Xcast6 (Explicit Multi-
unicast (Xcast) for IPv6), 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. The difference from the experimental
specification which is described in [5058] is that this version
eliminates Hop-by-Hop header which sometimes suffers hardware router.
"Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker,
8-Aug-08, <draft-bakker-sipping-3gpp-ims-xml-body-handling-01.txt>
This document registers new disposition-types for the Content-
Disposition header that apply to the application/3gpp-ims+xml body
used by 3GPP. The applicability of these content-disposition values
are limited to 3GPP IMS. The application/3gpp-ims+xml body has the
following two distinct uses: (1) for redirecting the emergency
session to use a different domain (e.g. using a Circuit Switched
call), and (2) for delivering user profile specific information from
the SIP registrar to an Application Server.
"A Binary Floor Control Protocol (BFCP) Control Package for the Media Control
Channel Framework", Lorenzo Miniero, Simon Romano, Roni Even, Scott
McGlashan, 8-Jul-08, <draft-miniero-bfcp-control-package-01.txt>
This document defines a Media Control Channel Framework Package for
BFCP-based conference moderation. The control of Media Servers and
their related resources in decomposed network architectures plays an
important role in various Next Generation Networks. This Control
Package aims at adding BFCP functionality to conferences using the
Media Control Channel Framework.
"Enabling an Enhanced Care-of Address Reachability Test for the Home Agent",
Wassim Haddad, Francis Dupont, 14-Jul-08,
<draft-haddad-mext-enhanced-reachability-test-02.txt>
This memo aims to improve Mobile IPv6 protocol security by enabling
an enhanced care-of address rechability test for the home agent. The
main goals are to discourage a rogue mobile node from misleading its
home agent to flood a targeted foreign network and to empower the
latter to thwart this type of attack if launched at a later stage.
"PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter,
11-Jun-08, <draft-joshi-pim-group-rp-mapping-01.txt>
Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a 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 allow administrator to override a specific Group-to-RP
mapping with the static Group-to-RP mapping which an administrator would
want to use. This algorithm also does not consider the PIM mode and the mechanism
through which a Group-to-RP mapping was learned.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.
"Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal
(DCCP-NAT)", Thomas Phelan, 31-Oct-08, <draft-phelan-dccp-natencap-02.txt>
This document specifies an alternative encapsulation of the Datagram
Congestion Control Protocol (DCCP), referred to as DCCP-NAT. This
encapsulation will allow DCCP to be carried through the current
generation of Network Address Translation (NAT) middleboxes without
modification of those middleboxes.
"More Features for TWAMP", Al Morton, Kaynam Hedayat, 13-Jul-08,
<draft-morton-ippm-more-twamp-02.txt>
The IETF is completing its work on TWAMP - the Two-Way Active
Measurement Protocol. This memo describes additional features for
TWAMP, essentially the ability to use different security modes in the
TWAMP-Control and TWAMP-Test protocols.
"RTP Payload Format for H.264 Video", Ye-Kui Wang, Stephan Wenger, Miska
Hannuksela, Thomas Stockhammer, Magnus Westerlund, David Singer, 14-Jul-08,
<draft-wang-avt-rfc3984bis-01.txt>
This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec. The RTP payload
format allows for packetization of one or more Network Abstraction
Layer Units (NALUs), produced by an H.264 video encoder, in each RTP
payload. The payload format has wide applicability, as it supports
applications from simple low bit-rate conversational usage, to
Internet video streaming with interleaved transmission, to high bit-
rate video-on-demand.
This memo intends to obsolete RFC 3984.
"Applicability Statement for the Use of Pre-Congestion Notification in a
Resource-Controlled Network", Tina Tsou, Fortune Huang, Tom Taylor, 3-Nov-08,
<draft-tsou-pcn-racf-applic-01.txt>
This document is written to help coordinate work on pre-congestion
notification (PCN) between the IETF PCN Working Group and the ITU-T.
It maps the use of PCN into the ITU-T transport control architecture.
It examines three scenarios, showing in each, where new requirements
are placed on the ITU-T architecture. In each case, the ITU-T
functional entity known as the Transport Resource Control Functional
Entity (TRC-FE) is seen as the logical destination for PCN congestion
reports and PCN flow termination reports, which it uses to keep track
of network status. As logical entities, instances of the TRC-FE can
be present in the ingress nodes, in one or more centralized devices,
or in both. These alternatives define the scenarios examined.
"SIP E.164 Problem Statement", John Elwell, 25-Oct-08,
<draft-elwell-sip-e164-problem-statement-01.txt>
SIP has long supported the use of both email-style addresses
(user@host) and telephone-style addresses (number@host) in the
"From:" address. A significant number of SIP deployments use the
latter style with E.164 numbers. This document describes the
problems that occur when such E.164 numbers are used in SIP.
"Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non
Session Initiation Protocol (SIP) Protocols", Jonathan Rosenberg, 14-Jul-08,
<draft-rosenberg-mmusic-ice-nonsip-01.txt>
Interative Connectivity Establishment (ICE) has been specified as a
NAT traversal mechanism for protocols based on the offer/answer
exchange model. In practice, only the Session Initiation Protocol
(SIP) has used ICE. This document provides guidance on how other
protocols can make use of ICE.
"Linguistic Guidelines for the Use of Arabic Characters in Internet Domains",
Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek,
22-Oct-08, <draft-farah-adntf-ling-guidelines-02.txt>
This document constitutes technical specifications for the use of
Arabic characters in Internet Domain names and provides linguistic
guidelines for Arabic Domain Names. It addresses Arabic-specific
linguistic issues pertaining to the use of Arabic language in domain
names.
"Session Based Trivial Object Transfer and Exchange (TOTE)", Jonathan
Rosenberg, 3-Nov-08, <draft-rosenberg-sip-tote-02.txt>
This document defines a simple protocol - Trivial Object Transfer and
Exchange (TOTE) - that provides bidirectional exchange of MIME
objects over a TCP connection. It is used in conjunction with
protocols based on the offer/answer model, such as the Session
Initiation Protocol (SIP). TOTE can be used for any application
requiring direct agent-to-agent data communication, such as picture
exchange or camera controls.
"Usage of Host Generating Interface Identifier in DHCPv6", Frank Xia, Behcet
Sarikaya, Sheng Jiang, 1-Nov-08, <draft-xia-dhc-host-gen-id-01.txt>
This document describes a procedure for configuring a host's IPv6
address which prefix is allocated from a DHCPv6 server while it's
interface identifier is independently generated by the host. The
method is applicable to Cryptographically Generated Addresses (CGA).
"IPFRR in the Presence of Multiple Failures", Stewart Bryant, Mike Shand,
30-Oct-08, <draft-bryant-shand-ipfrr-multi-01.txt>
IP Fast Reroute (IPFRR) work in the IETF has focused on the single
failure case, where the failure could be a link, a node or a shared
risk link group. This draft describes possible extensions to not-via
IPFRR that under some circumstances allow the repair of multiple
simultaneous failures.
"Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO
Method", Jonathan Rosenberg, 3-Nov-08,
<draft-rosenberg-sip-info-litmus-02.txt>
The Session Initiation Protocol (SIP) Working Group is considering
the standardization of a framework for conveying application data
through the INFO method. However, the INFO method is just one of
several techniques available in SIP for the transfer of application
data. Others include through the SIP events framework and through a
media session. This document provides guidelines and litmus tests
for determining which is the right technique to use.
"DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V.
Ramakrishna Rao, Bharat Joshi, 16-Jun-08,
<draft-kurapati-dhc-leasequery-by-remote-id-01.txt>
Some Relay Agents extract lease information from the DHCP message
exchanged between the client and DHCP server. This lease information
is used by relay agents for various purposes like antispoofing,
prevention of flooding. RFC 4388 defines a mechanism for relay
agents to retrieve the lease information from the DHCP server as and
when this information is lost. Existing leasequery mechanism is data
driven which means that a relay agent can initiate the leasequery only when
it starts receiving data from/to the clients. In certain scenarios, this
model is not scalable. This document first looks at issues in existing mechanism
and then proposes a new query type, query by remote ID, to address these
issues.
"ILNP Concept of Operations", Randall Atkinson, 11-Jun-08,
<draft-rja-ilnp-intro-01.txt>
This documents the Concept of Operations for an experimental
extension to IPv6 which is known as the Identifier Locator
Network Protocol (ILNP).
"Conventions for the Use of the Session Description Protocol (SDP) for
Circuit-Switched Bearer Connections in the Public Switched Telephone Network
(PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 30-Oct-08,
<draft-garcia-mmusic-sdp-cs-02.txt>
This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio media streams over circuit-switched bearers in
the Public Switched Telephone Network (PSTN).
"Updates to LDP for IPv6", Vishwas Manral, Rajiv Papneja, 4-Sep-08,
<draft-manral-mpls-ldp-ipv6-02.txt>
LDP is defined in [RFC5036]. LDP (for Label Distribution Protocol)
defines procedures for LSRs to distribute labels to support MPLS
forwarding along normally routed paths.
LDP is a protocol defined for distributing labels. It is the set of
procedures and messages by which Label Switched Routers (LSRs) establish
Label Switched Paths (LSPs) through a network by mapping network-layer
routing information directly to data-link layer switched paths. These LSPs
may have an endpoint at a directly attached neighbor (comparable to IP
hop-by-hop forwarding), or may have an endpoint at a network egress node,
enabling switching via all intermediary nodes.
The LDP procedures are defined for both IPv4 and IPv6 networks. This
document corrects and clarifies the LDP behavior for IPv6 networks as
defined in [RFC5036] for helping in better interoperability between
implementations.
"TraceFlow", Arun Viswanathan, Subi Krishnamurthy, Rajeev Manur, Vishal
Zinjuvadia, 16-Aug-08, <draft-zinjuvadia-traceflow-02.txt>
This document describes a new OAM protocol - TraceFlow that captures
information pertaining to a traffic flow along the path that the flow
takes through the network. TraceFlow is ECMP and link-aggregation
aware and captures the information about constituent members through
which the traffic flow passes. TraceFlow gathers information that is
relevant to the flow such as interface address, interface statistics,
effect of network policies on the flow and so on.
"Mechanisms for safely abandoning loop-free convergence (AAH)", Mike Shand,
Stewart Bryant, Pierre Francois, 31-Oct-08,
<draft-bryant-francois-shand-ipfrr-aah-01.txt>
IPFRR and loop-free convergence techniques can deal with single
topology change events, multiple correlated change events, and in
some cases even certain uncorrelated events. However, in all cases
there are events which cannot be dealt with and the mechanism needs
to quickly revert to normal convergence. This is known as
"Abandoning All Hope" (AAH). This document describes the nature of
the problem, and various proposed mechanisms to deal with it.
"Stream Control Transmission Protocol (SCTP)-Based Media Transport in the
Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo,
3-Nov-08, <draft-loreto-mmusic-sctp-sdp-02.txt>
SCTP (Stream Control Transmission Protocol) is a transport protocol
used to establish associations between two endpoints. This document
describes how to express media transport over SCTP in SDP (Session
Description Protocol). This document defines the 'SCTP' protocol
identifier for SDP.
"A BGP Inter-AS Cost Attribute", Iljitsch van Beijnum, 3-Nov-08,
<draft-van-beijnum-idr-iac-01.txt>
Although BGP implementations have extensive path selection
algorithms, in practice operators have trouble performing
satisfactory traffic engineering of incoming traffic based on BGP
attributes that are taken into account in the path selection
algorithm alone. For this reason, many ASes deaggregate their
address range(s) into smaller blocks and announce these blocks
differently to different neighboring ASes in order to arrive at the
desired traffic flow. This practice contributes to the growth of the
global routing table, which drives up capital expenditures for
networks engaging in inter-domain routing. This memo introduces a
new inter-domain metric that supports finer-grained traffic
engineering than current BGP attributes.
"Locater ID proposal evaluation", Anne-Louise Burness, Philip Eardley, Luigi
Iannone, 14-Jul-08, <draft-burness-locid-evaluate-01.txt>
There are many proposals for improving the Inter-domain routing
system, most of which involve a form of locater-identity split.
There needs to be a means to reason about the strengths of the
different proposals against the design criteria, and without
requiring large scale implementations. This document aims to start
this process by drawing parallels with existing systems. It
identifies a number of questions that need to be more fully thought
about whilst we press ahead with system development.
"Usecases and Benefits of end to end ECN support in PCN Domains",
Zaheduzzaman Sarker, Ingemar Johansson, 20-Nov-08,
<draft-sarker-pcn-ecn-pcn-usecases-02.txt>
This document provides an informative overview of possible use cases
where ECN marking can be used for inelastic traffic. It outlines
benefits of preserving the ECN support in a PCN domain. As ECN
provides with a simple mechanism for network nodes to inform the end
points about possible upcoming congestion and resulting packet losses
and delay increase, the scheme can be useful for adaptive real-time
media applications, thus enabling them to adjust the transmission
rate to avoid quality degradation due to congestion. By showing the
benefits of ECN this memo asks the working group to consider end to
end ECN support in PCN domain.
"OpenLISP Implementation Report", Luigi Iannone, Damien Saucez, Olivier
Bonaventure, 16-Jul-08, <draft-iannone-openlisp-implementation-01.txt>
The RRG is working on the design of an alternate Internet
Architecture in order solve issues of the current architecture
related to scalability, mobility, multi-homing, and inter-domain
routing. Among the various proposals, LISP (Locator/ID Separation
Protocol) is one of the most advanced. The present draft describes
the overall architecture of OpenLISP, an open source implementation
of the LISP proposal. Further, the draft contains some general
remarks concerning the design and the implementation of the LISP
protocol.
"HIP Certificates", Tobias Heer, Samu Varjonen, 14-Jul-08,
<draft-varjonen-hip-cert-01.txt>
This document specifies a certificate parameter called CERT for the
Host Identity Protocol (HIP). The CERT parameter is a container for
Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates.
It is used for carrying these certificates in HIP control messages.
Additionally, this document specifies the representations of Host
Identity Tags in SPKI and X.509.v3 certificates.
"IDIPS : ISP-Driven Informed Path Selection", Damien Saucez, Benoit Donnet,
Olivier Bonaventure, 3-Nov-08, <draft-saucez-idips-01.txt>
This draft describes a simple network-based protocol to facilitate
Path Selection and to improve traffic engineering capabilities in
multihomed corporate networks. With the protocol, any network device
that requires to select a path among a list of different paths asks a
Traffic Engineering service called IDIPS (ISP-Driven Informed Path
Selection) to obtain an ordered list of the possible paths. The
ordering is constructed according to the policies and performances
requirements of both the host and network provider.
"Using Imprecise Location for Emergency Context Resolution", Richard Barnes,
Matt Lepinski, 4-Nov-08, <draft-barnes-ecrit-rough-loc-01.txt>
Emergency calling works best when precise location is available for
emergency call routing. However, there are situations in which a
location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls. This
document describes the level of location accuracy that providers must
provide to enable emergency call routing. In addition, we descibe
how emergency services and non-emergency services can be invoked by
an endpoint that does not have access to its precise location.
"Mobile IPv6 Residual Threats", Wassim Haddad, George Tsirtsis, Benjamin Lim,
Suresh Krishnan, Francis Dupont, 14-Jul-08,
<draft-haddad-mext-mip6-residual-threats-02.txt>
This memo aims to highlight specific "residual" threats in Mobile
IPv6 protocol. We call these threats "residual" simply because they
were rightfully deemed not urgent during the design of Mobile IPv6
protocol. However, these threats are somehow benefiting from new
mechanisms and/or extensions built on top of Mobile IPv6 protocol to
improve their effects and likelihood. Hence, our main goal is to
motivate designers to re-assess their potential taking into
consideration these new mechanisms.
"The Session Initiation Protocol (SIP) P-Private-Network-Indication
Private-Header (P-Header)", Hans Erik van Elburg, Keith Drage, 11-Jul-08,
<draft-vanelburg-sipping-private-network-indication-02.txt>
This document describes why a private network indication is needed.
A private network indication allows other nodes in a network to treat
private network traffic to a different set of rules then public
network traffic. The indication also distinguishes one private
network from another private network.
"Vendor Specific Message for ANCP.", Peter Arberg, 3-Nov-08,
<draft-arberg-ancp-vendorspecific-01.txt>
This document is aimed at presenting Access Node Control Protocol
(ANCP) with vendor specific protocol extensions.
"SIP Usage Scenarios Similar to SPIT", Dan York, 14-Jul-08,
<draft-york-sipping-spit-similarity-scenarios-01.txt>
This document outlines scenarios in which legitimate SIP traffic may
appear similar to traffic associated with voice spam, also known as
"SPIT" or "Spam for Internet Telephony. This document is created to
provide input into the current discussions about how best to address
the issue of SPIT.
"Diameter ITU-T Rw Policy Enforcement Interface Application", Dong Sun,
18-Nov-08, <draft-sun-dime-itu-t-rw-02.txt>
This document describes the need for a new pair of IANA Diameter
Command Codes to be used in a vendor-specific new application, namely
for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/
responses for authorizing network QoS resources and policy
enforcement in a network element, as one of the recommendations of
the International Telecommunication Union - Telecommunication
Standardization Sector (ITU-T).
"The Uniform Resource Identifier (URI) DNS Resource Record", Patrik
Faltstrom, Olaf Kolkman, 3-Nov-08, <draft-faltstrom-uri-02.txt>
This document defines a new DNS resource record, called the Uniform
Resource Identifier (URI) RR, for publishing mappings from hostnames
to URIs.
"Simultaneous Mobility Problem Statement", Daniel Wong, Ashutosh Dutta,
Henning Schulzrinne, 10-Jul-08, <draft-wong-mext-simultaneous-ps-01.txt>
This document provides a problem statement for simultaneous mobility
in an infrastructure-based mobility environment. It considers what
the simultaneous mobility problem is and describes the conditions
under which it may occur. It also illustrates the occurrence of the
simultaneous mobility problem in the context of different mobility
protocols such as Mobile IPv6. The simultaneous mobility problem
defined here is strictly applied to scenarios when the intermediary
nodes in the core are not mobile.
"P-Charge-Info - A Private Header (P-Header) Extension to the Session
Initiation Protocol (SIP)", Dan York, Tolga Asveren, 3-Nov-08,
<draft-york-sipping-p-charge-info-05.txt>
This document describes 'P-Charge-Info', a private Session Initiation
Protocol (SIP) header (P-header) used to convey billing information
about the party to be charged. This P-Header is currently in
production usage by a number of equipment vendors and carriers and
this document is submitted to request the registration of this header
with IANA as required by section 4.2 of RFC 3427. This P-Header may
also be used in some situations to carry the ISUP Charge Number
parameter for PSTN interconnection.
"ProxyMIP Extension for Inter-MAG Route Optimization", Ashutosh Dutta, Subir
Das, Hidetoshi Yokota, Tsunehiko Chiba, Henning Schulzrinne, 13-Jul-08,
<draft-dutta-netlmm-pmipro-01.txt>
This draft describes a light weight route optimization technique that
helps to optimize the media path between two communicating nodes when
Proxy MIP is used as the mobility protocol. This routing
optimization technique is most useful when the two communicating
hosts are away from home and need to communicate with each other
using an optimized path. It takes advantage of the data packet
between LMA and MAG to set up the optimized data path between the
communicating hosts. This route optimization technique is applicable
to both the intra-LMA and inter-LMA scenarios.
"RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", Ali
Begen, 11-Sep-08, <draft-begen-fecframe-1d2d-parity-scheme-01.txt>
This document defines new RTP payload formats for the Forward Error
Correction (FEC) that is generated by the non-interleaved and
interleaved parity codes from a source media encapsulated in RTP.
These parity codes are systematic codes, where a number of repair
symbols are generated from a set of source symbols and sent in a
repair flow separate from the source flow that carries the source
symbols. The non-interleaved and interleaved parity codes offer a
good protection against random and bursty packet losses,
respectively, at a cost of decent complexity. The RTP payload
formats that are defined in this document address the scalability
issues experienced with the earlier specifications including RFC
2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due
to these changes, the new payload formats are not backward compatible
with the earlier specifications.
"Provisioning Protocol Requirements for ENUM-SIP Addressing Servers", Tom
Creighton, Jean-Francois Mule, 14-Jul-08,
<draft-mule-peppermint-espp-requirements-01.txt>
This document presents use cases and protocol requirements for
provisioning ENUM-SIP addressing servers. The provisioned data is
used by the addressing server to return session establishment data
for SIP entities to route SIP requests to the target destinations.
An ENUM-SIP addressing server acts as a Lookup Function in session
peering to determine the target domain of a given SIP request. It
may also act as a Location Routing Function to develop the location
of the SIP signaling entity in the target domain.
"A Provisioning Protocol for ENUM-SIP Addressing Servers", Kenneth
Cartwright, Stephen Dimig, Mark Teodoro, Jean-Francois Mule, 14-Jul-08,
<draft-mule-peppermint-espp-protocol-02.txt>
This document defines a provisioning protocol for ENUM-SIP addressing
servers.
An ENUM-SIP addressing server is a host that acts as Lookup Function
in session peering to determine the target domain of a given SIP
request and it may also act as a Location Routing Function to develop
the location of the SIP signaling entity in that target domain.
This protocol allows SIP service providers to provision and manage
session establishment data used by SIP network elements to route SIP
sessions to the target destinations which may be served by the SIP
service provider's own internal network or by a session peering
partner. The data provisioned into an ENUM-SIP addressing server is
queried by SIP entities using ENUM or SIP.
This version of the protocol integrates comments received on the IETF
peppermint and drinks mailing lists before July 2008. This document
is an Internet-Draft and the protocol it describes is subject to
technical changes that may make this version incompatible with future
versions defined in Internet-Drafts. It is expected that the authors
will continue to update this protocol based on the drinks working
group requirements on the session establishment data.
"Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin
Perkins, 15-Jun-08, <draft-ott-avt-rtcp-guidelines-01.txt>
The RTP Control Protocol (RTCP) is used along with the Real-time
Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to
enable application adaptivity and monitoring, among other uses. The
basic reporting mechanisms offered by RTCP are generic, yet quite
powerful and suffice to cover a range of uses. This document
provides guidelines on extending RTCP if those basic mechanisms prove
insufficient.
"Representing Netconf Data Models using Document Schema Definition Languages
(DSDL)", Rohan Mahy, Sharon Chisholm, Ladislav Lhotka, 8-Jul-08,
<draft-mahy-canmod-dsdl-02.txt>
This document describes a concrete approach for representing Netconf
and other IETF data models using the RelaxNG schema language and the
Schematron validation language, which are both part of ISO's Document
Schema Definition Languages (DSDL) standard.
"Hierarchical Host Identity Tag Architecture", Sheng Jiang, 28-Oct-08,
<draft-jiang-hiprg-hhit-arch-01.txt>
This document analyzes the problems and limitation of the current
flat-structured Host Identity Tag architecture. The document
specifies a hierarchical HIT architecture which is compatible with
the flat-structured HIT architecture. This architecture and the
process of HITs generation ensure the global uniqueness of HITs. It
also enables the multiple Host Identity Protocol management domains,
solves the deployment problem of current flat-structured HIT
architecture. It also enhances the scalability and resolution
efficiency of the mapping system.
"Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki,
14-Jul-08, <draft-otani-pce-gmpls-aps-req-02.txt>
The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element).
"Routing System Stability", Dimitri Papadimitriou, James Lowe, 29-Jul-08,
<draft-dimitri-grow-rss-03.txt>
Understanding the dynamics of the Internet routing system is
fundamental to ensure its robustness/stability and to improve the
mechanisms of the BGP routing protocol. This documents outlines a
program of activity for identifying, documenting and analyzing the
dynamic properties of the Internet and its routing system.
"Kerberos Option for DHCPv6", Masahiro Ishiyama, Shoichi Sakane, 30-Oct-08,
<draft-sakane-dhc-dhcpv6-kdc-option-03.txt>
This document defines a new DHCPv6 option to carry a set of
configuration information related to the Kerberos protocol [RFC4120].
This document also defines three sub-options to be used in this new
option, which specify a realm name of the Kerberos, a list of IP
addresses of the Key Distribution Center of that realm and a client
principal name to distinguish a Kerberos client by the DHCPv6 server.
"Ivip Mapping Database Fast Push", Robin Whittle, 20-Aug-08,
<draft-whittle-ivip-db-fast-push-01.txt>
Ivip (Internet Vastly Improved Plumbing) is a proposed map-encap
system which is intended to provide a solution for the routing
scaling problem - supporting growing numbers of end-user networks
with multihoming, traffic engineering and portability, without
further growth in the global BGP routing table. Ivip is also
intended to provide other benefits, including a new form of IPv4 and
IPv6 mobility and better utilization of IPv4 address space. To
achieve these benefits, Ivip relies on a "fast mapping database push"
system, which is required to securely and reliably deliver updates to
the mapping database to hundreds of thousands - or potentially
millions - of ITRs (Ingress Tunnel Routers) and Query Servers (QSes)
all over the Net, ideally within a few seconds. This ID describes
the requirements of such a system and how it could be implemented so
as to cope with very large numbers of updates and ITR/QS sites.
"RBridges: Use of IS-IS", Donald Eastlake 3rd, Radia Perlman, Dinesh Dutt,
3-Nov-08, <draft-eastlake-trill-rbridge-isis-02.txt>
RBridges implement the TRILL protocol, which in turn makes use of an
extended version of the IS-IS (Intermediate System to Intermediate
System) routing protocol to determine topology and frame forwarding
and for the distribution and synchronization of data. RBridges
provide optimal pair-wise forwarding with zero configuration, safe
forwarding even during periods of temporary loops, and multipathing
for both unicast and multicast traffic. Rbridges also support VLANs.
This document specifies some details of IS-IS PDUs used in TRILL.
"EAP Method Support for Transporting AAA Payloads", Charles Clancy,
31-Jul-08, <draft-clancy-emu-aaapay-01.txt>
This document defines bindings for existing EAP methods to transport
Diameter AVPs, called "AAA payloads". The primary application is to
support EAP channel bindings, but this could be used for other
applications as well.
"Channel Binding Support for EAP Methods", Charles Clancy, Katrin Hoeper,
3-Nov-08, <draft-clancy-emu-chbind-04.txt>
This document defines how to implement channel bindings for
Extensible Authentication Protocol (EAP) methods to address the lying
NAS problem.
"Cryptographic Algorithm Implementation Requirements for Routing Protocols",
Manav Bhatia, Vishwas Manral, 3-Nov-08,
<draft-bhatia-manral-igp-crypto-requirements-02.txt>
The interior gateway routing protocols OSPFv2 [RFC2328], IS-IS [ISO]
[RFC1195] and RIP [RFC2453] currently define clear text and MD5
[RFC1321] algorithms for authenticating their protocol packets. There
have recently been documents adding support of the Secure Hash
Algorithm (SHA) family of hash functions for authenticating routing
protocol packets for RIP [RFC4822], IS-IS and OSPF.
To ensure interoperability between disparate implementations, it is
imperative that we specify a set of mandatory-to-implement algorithms
thereby ensuring that there is at least one algorithm that all
implementations will have available.
This document defines the current set of mandatory-to-implement
algorithms to be used for the cryptographic authentication of these
routing protocols as well as specifying the algorithms that should be
implemented because they may be promoted to mandatory at some future
time.
"Security Parameter Index multiplexed Network Address Translation (SPINAT)",
Jan Melen, Jukka Ylitalo, Patrik Salmela, 27-Jul-08,
<draft-melen-spinat-01.txt>
This drafts defines a Security Parameter Index multiplexed Network
Address Translator (SPINAT). The SPINAT method uses the SPI value of
ESP packets to de-multiplex multiple IP addresses on single IP
address. The solution presented in this draft requires a state in
the SPINAT node and in the peer node. The state establishment
requires a control signaling messages carrying the SPI values.
"Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui,
28-Jul-08, <draft-hui-6lowpan-hc-01.txt>
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. This
document specifies compression of well-known multicast addresses and
a framework for compressing next headers. UDP compression is
specified within this framework.
"Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood,
Peter Holliday, 31-Oct-08, <draft-wood-dtnrg-http-dtn-delivery-02.txt>
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.
"Sender Policy Framework: Email Address Internationalization", Frank
Ellermann, 7-Sep-08, <draft-ellermann-spf-eai-04.txt>
UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol)
allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address
Internationalization) and message headers. This memo discusses the
consequences for SPF (Sender Policy Framework).
"6LoWPAN Backbone Router", Pascal Thubert, 10-Jul-08,
<draft-thubert-6lowpan-backbone-router-01.txt>
ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process
Control. The WG is mandated to design a scalable, industrial grade
LowPAN for devices such as sensors, valves, and actuators. The
upcoming standard uses the 6LoWPAN format for the network header. It
also introduces the concept of a Backbone Router to merge small
LoWPANs via a high speed transit and scale the ISA100.11a network.
This paper proposes an IPv6 version of the Backbone Router concept.
"LoWPAN simple fragment Recovery", Pascal Thubert, 29-May-08,
<draft-thubert-6lowpan-simple-fragment-recovery-02.txt>
Considering that 6LoWPAN packets can be as large as 2K bytes and that
an 802.15.4 frame with security will carry in the order of 80 bytes
of effective payload, a packet might end up fragmented into as many
as 25 fragments at the 6LoWPAN shim layer. If a single one of those
fragments is lost in transmission, all fragments must be resent,
further contributing to the congestion that might have caused the
initial packet loss. This draft introduces a simple protocol to
recover individual fragments between 6LoWPAN endpoints.
"Robust Header Compression over Unidirectional Lightweight Encapsulation
(ULE) and MPEG2 Transport Stream (TS) frames", Tat-Chee Wan, Way-Chuang Ang,
Chee-Hong Teh, 16-Oct-08, <draft-wan-ipdvb-rohc-02.txt>
This document describes a set of Extension Headers for the
Unidirectional Lightweight Encapsulation (ULE), RFC4326 to carry
packets compressed with RObust Header Compression (ROHC), RFC 3095
over ULE Stream.
"Streamlined FTP Command Extensions", Mark Peterson, Rhino Software,
29-Aug-08, <draft-peterson-streamlined-ftp-command-extensions-06.txt>
This document specifies FTP commands to download thumbnails of remote
images, remove entire directory trees, request the amount of storage
space available to the user, request the size of a remote directory
and its contents, and to specify an FTP host. The commands are
designed to reduce the number of server / client exchanges, provide
information that was not previously available, and to reduce
bandwidth requirements for some higher level operations.
"Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and
analysis", Jong-Hyouk Lee, Byung-Jin Han, Tai-Myoung Chung, Hyung-Jin Lim,
20-Sep-08, <draft-jhlee-netlmm-nemo-scenarios-01.txt>
As Proxy Mobile IPv6 is deployed, a Mobile Network will be
initialized in or move to a Proxy Mobile IPv6 domain. In this
document, the scenarios of Network Mobility Basic Support within
Proxy Mobile IPv6 that ensure session continuance for all nodes in the Mobile
Network are presented. In addition, an analysis of all scenarios that comprise
the interactions between Network Mobility Basic Support and Proxy Mobile
IPv6 is provided as a guideline to PMIPv6 deployments.
"Chrysolite - a backbone bridging solution", Mohammad Yousuf, Matthew Thomas,
David Hunter, 16-Jun-08, <draft-yousuf-thomas-hunter-rtgwg-bb-02.txt>
Chrysolite is a combination of differing technologies to create a
wide area switched Ethernet solution. Each Chrysolite switch has a
unique MAC address (N-MAC). A link state protocol provides pairwise
shortest paths between the N-MACs (one N-MAC per switch).
Customers connect to the Chrysolite cloud using Ethernet connections.
By setting the locally administered bit in the Ethernet address used
to connect to the Chrysolite cloud, customers can directly
encapsulate traffic into assigned source and destination C-MAC (MAC)
addresses.
Each of these C-MAC addresses specifies a unique customer 'VLAN
circuit'. This proves end to end paths across the Chrysolite cloud
without requiring any special headers, MAC in MAC or Q-in-Q
encapsulation.
"Filename Preservation for EDIINT Protocol", Terry Harding, 17-Nov-08,
<draft-harding-ediint-filename-preservation-01.txt>
The intent of this document is to be placed on the RFC track as an
Informational RFC.
"Behavior of Collocated HA/LMA", George Tsirtsis, Suresh Krishnan, 22-Oct-08,
<draft-tsirtsis-logically-separate-lmaha-01.txt>
In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario
C describes the case of collocation of LMA and HA function. In this
case a PMIP network emulates the "home link" for MNs using MIPv6.
This document argues that even when LMA and HA functions are
Collocated they MUST be treated as logically separate entities. In
particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6
BCEs and vice versa.
"The BagIt File Package Format (V0.95)
http://www.ietf.org/internet-drafts/draft-kunze-bagit-02.txt", Andy Boyko,
John Kunze, Justin Littman, Liz Madden, 11-Jul-08, <draft-kunze-bagit-02.txt>
This document specifies BagIt, a hierarchical file package format for
the exchange of generalized digital content. A "bag" has just enough
structure to safely enclose a brief "tag" and a payload but does not
require any knowledge of the payload's internal semantics. This
BagIt format should be suitable for disk-based or network-based file
package transfer. One important use case is the possibility of
eventual safe return of a received bag. Tag information consists of
a small number of top-level reserved file names, checksums for
transfer validation, and optional small metadata blocks.
"Host Identity Protocol based Mobile Router (HIPMR)", Jan Melen, Jukka
Ylitalo, Patrik Salmela, 27-Jul-08, <draft-melen-hip-mr-01.txt>
This drafts defines a moving network support for HIP enabled hosts.
The protocol uses asymmetric authentication and symmetric
authorization. The solution presented in this draft is based on
delegation of signalling rights between mobile nodes and mobile
routers that results in route optimization between end-hosts.
"X.509 Key and Signature Encoding for the KeyNote Trust Management System",
Angelos Keromytis, 1-Oct-08, <draft-keromytis-keynote-x509-01.txt>
This memo describes X.509 key identifiers and signature encoding
for version 2 of the KeyNote trust-management system [KEYNOTE].
X.509 certificates [RFC3280] can be directly used in the Authorizer
or Licensees field (or in both fields) in a KeyNote assertion,
allowing for easy integration with protocols that already use X.509
certificates for authentication.
In addition, the document defines additional signature types that
use other hash functions (beyond the MD5 and SHA1 hash functions
that are defined in [RFC2792]).
"A Quick Crash Detection Method for IKE", Yoav Nir, Frederic Detienne,
Pratima Sethi, 12-Oct-08, <draft-nir-ike-qcd-03.txt,.pdf>
This document describes an extension to the IKEv2 protocol that
allows for faster detection of SA desynchronization using a saved
token.
When an IPsec tunnel between two IKEv2 peers is disconnected due to a
restart of one peer, it can take as much as several minutes for the
other peer to discover that the reboot has occurred, thus delaying
recovery. In this text we propose an extension to the protocol, that
allows for recovery immediately following the restart.
"IANA Registrations for the 'Send-N' Enumservice", Ray Bellis, 23-Jun-08,
<draft-bellis-enum-send-n-02.txt>
This document requests IANA registration of an Enumservice 'Send-N'
and extends the definition of the 'pstndata' URI scheme. This
service allows more efficient support for overlapped dialling in
E.164 Number Mapping (ENUM) applications.
"Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 6-Jul-08,
<draft-brasher-diap-02.txt>
A de-centralised, self-contained and managed storage protocol. A
system to provide strong storage fail over by using existing
resources over networks distributing vital data evenly. Rapid
deployment and high redundancy for small to medium organisations as
well as individuals. Designed to reduce dependency on tape backup
systems. The protocol also has implications for long term archiving.
By classifying data vitality values the limitations in physical space
due to bandwidth constrictions can be overcome and the usefulness of
DIAP maximised.
"A Scalable IPv4-IPv6 Transition Architecture Need for an
address-port-borrowing-protocol (APBP)", Remi Despres, 14-Jul-08,
<draft-despres-v6ops-apbp-01.txt>
This document discusses, for the IPv4-IPv6 coexistence period, the
combined requirement that: (1) legacy IPv4 hosts can establish IPv4
transport connection s from customer sites having IPv6-only permanent
addresses; (2) for good scalability, no network address translations
(NATs), and a fortiori no application level gateways (ALGs), need to
be supported within network infrastructures. To satisfy this
requirement, it is concluded that an address-port-borrowing-protocol
(APBP) is needed.
"Conveying Vendor-Specific Constraints in the Path Computation Element
Protocol", Adrian Farrel, Greg Bernstein, 2-Nov-08,
<draft-farrel-pce-vendor-constraints-02.txt>
The Path Computation Element Protocol (PCEP) is used to convey path
computation requests and responses between Path Computation Clients
(PCCs) and Path Computation Elements (PCEs), and also between
cooperating PCEs. In PCEP the path computation requests carry details
of the constraints and objective functions that the PCC wishes the
PCE to apply in its computation.
The mechanisms defined for indicating objective functions include
the capability to convey vendor-specific objective functions. This
document defines a facility to carry vendor-specific constraints in
PCEP.
"Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann,
Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08,
<draft-wunderlich-openmesh-manet-routing-00.txt>
This document specifies a simple and robust algorithm for
establishing multi-hop routes in mobile ad-hoc networks. It ensures
highly adaptive and loop-free routing while causing only low
processing and traffic cost.
"Application-Layer Traffic Optimization (ALTO) Problem Statement", Enrico
Marocco, Vijay Gurbani, 2-Nov-08,
<draft-marocco-alto-problem-statement-03.txt>
A significant part of the Internet traffic today is generated by
peer-to-peer applications used, for example, for file sharing,
realtime communications and live media streaming. Such applications
often deal with large amounts of data in direct peer-to-peer
connections, but they usually have little knowledge of the underlying
network topology. As a result, they may choose their peers based on
measurements and statistics which, in some situations, may lead to
suboptimal choices. This document describes problem related to
optimizing traffic generated by peer-to-peer applications through the
use of network-layer information, provides a representative set of
use cases that may exhibit this problem, and outlines considerations
that have to be taken in account when arriving at equitable
solutions.
"PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai,
28-Oct-08, <draft-kumaki-murai-pce-pcep-extension-l3vpn-01.txt>
It is highly desirable for VPN customers to be able to dynamically
establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In
such a scenario, it is advantageous to use PCE to calculate customer
MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP-
VPNs.
"Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network
Management Protocol (SNMP) Notifications", Juergen Schoenwaelder, Alex Clemm,
Anirban Karmakar, 3-Nov-08, <draft-schoenw-syslog-msg-mib-01.txt>
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 mapping of SYSLOG messages to Simple
Network Management Protocol (SNMP) notifications.
"Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc
Petit-Huguenin, 8-Oct-08, <draft-petithuguenin-behave-turn-uri-03.txt>
This document defines two URI schemes and the resolution mechanism to
convert these URIs to a list of server transport addresses that can
be used between a Traversal Using Relays around NAT (TURN) client and
server.
"PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo
Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams, 24-Apr-08,
<draft-bberry-rfc4938bis-00.txt>
This document extends the Point-to-Point over Ethernet (PPPoE)
Protocol with an optional credit-based flow control mechanism and
an optional Link Quality Metric report. These optional extensions
improve the performance of PPPoE over media with variable bandwidth
and limited buffering, such as mobile point-to-point radio links.
"A Taxonomy for New Routing and Addressing Architecture Designs", Joel
Halpern, 12-Jul-08, <draft-halpern-rrg-taxonomy-01.txt>
The Routing Research Group is tasked to design a new routing
architecture to meet the challenges of scalability in face of
pervasive multi-homing and inter-domain traffic engineering. A
number of solutions have been proposed. This draft describes a
taxonomy for the design space.
"Marking behaviour of PCN-nodes", Philip Eardley, 26-Jun-08,
<draft-eardley-pcn-marking-behaviour-01.txt>
This document standardises the two marking behaviours of PCN-nodes:
threshold marking and excess traffic marking. Threshold marking
marks all PCN-packets if the PCN traffic rate is greater than a first
configured rate. Excess traffic marking marks a proportion of PCN-
packets, such that the amount marked equals the traffic rate in
excess of a second configured rate.
"Extended Random Values for TLS", Eric Rescorla, Margaret Salter, 1-Nov-08,
<draft-rescorla-tls-extended-random-01.txt>
This document describes an extension for using larger client and
server Random values with Transport Layer Security (TLS) and Datagram
TLS (DTLS).
"ECC in OpenPGP", Andrey Jivsov, 6-Jul-08,
<draft-jivsov-openpgp-ecc-01.txt,.pdf>
This document proposes an Elliptic Curve Cryptography extension to
the OpenPGP public key format and specifies three Elliptic Curves
that enjoy broad support by other standards, including NIST
standards. The document aims to standardize an optimal but narrow
set of parameters for best interoperability and it does so within
the framework it defines that can be expanded in the future to
allow more choices.
"MAC Security Label Requirements for NFSv4", David Quigley, James Morris,
24-Jun-08, <draft-quigley-nfsv4-sec-label-requirements-01.txt>
This Internet-Draft outlines high-level requirements for the
integration of flexible Mandatory Access Control (MAC) functionality
into NFSv4.1 . It describes the level of protections that should be
provided over protocol components and the basic structure of the
proposed system. It also gives a brief explanation of what kinds of
protections MAC systems offer and why existing NFSv4 protection
mechanisms are not sufficient.
"AtomPub Multipart Media Resource Creation", Joe Gregorio, 6-Oct-08,
<draft-gregorio-atompub-multipart-04.txt>
This specification defines how an Atom Publishing Protocol collection
may process multipart/related requests and also defines how a service
announces that it accepts multipart/related entities.
"A Session Initiation Protocol (SIP) Event Package for Debugging", Peter
Dawes, Vodafone Group, 29-Oct-08, <draft-dawes-sipping-debug-event-01.txt>
This document defines a Session Initiation Protocol (SIP) event
package for debugging. An entity that subscribes to this event
package for an address of record receives configuration data that
controls logging of SIP signalling for that address of record, for
example when to begin an end logging.
"Private Extension to the Session Initiation Protocol (SIP) for Debugging",
Peter Dawes, Vodafone Group, 29-Oct-08, <draft-dawes-sipping-debug-id-01.txt>
Networks that use SIP to start and stop sessions between their users
will frequently be upgraded with software and hardware changes.
Users will similarly frequently change their client software and the
way they use the network. In order to allow troubleshooting and
regression testing, it is useful to provide debugging as part of the
network fabric. This draft describes a SIP private header that
triggers logging of SIP signalling and identifies logs at mulitiple
SIP entities as belonging to a single end-to-end session.
"Indication of support for keep-alive", Christer Holmberg, 27-Oct-08,
<draft-holmberg-sip-keep-02.txt>
This specification defines a new SIP Via header parameter, "keep"
which SIP entities can use to indicate support of the NAT keep-alive
techniques defined in SIP Outbound, in cases where the Outbound
procedures are not supported or cannot be applied.
"Overview of Existing Routing Protocols for Low Power and Lossy Networks",
Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 8-Aug-08,
<draft-levis-roll-protocols-survey-02.txt>
Networks of low power wireless devices introduce novel IP routing
issues. Low-power wireless devices, such as sensors, actuators and
smart objects, have difficult constraints: very limited memory,
little processing power, and long sleep periods. As most of these
devices are battery-powered, energy efficiency is critically
important. Wireless link qualities can vary significantly over time,
requiring protocols to make agile decisions yet minimize topology
change energy costs. Routing over such low power and lossy networks
has requirements that existing mesh protocols only partially address.
This document provides a brief survey of the strengths and weaknesses
of existing protocols with respect to this class of networks. It
provides guidance on how lessons from existing and prior efforts can
be leveraged in future protocol design.
"WebDAV Current Principal Extension", Wilfredo Sanchez, Cyrus Daboo,
31-Oct-08, <draft-sanchez-webdav-current-principal-02.txt>
This specification defines a new WebDAV property that allows clients
to quickly determine the principal corresponding to the current
authenticated user.
"DKIM Author Domain Signing Practices (ADSP)", Table Contents, Author
Address, Douglas Otis, 25-Jun-08, <draft-otis-dkim-adsp-04.txt>
DomainKeys Identified Mail (DKIM) as described in [RFC4871], defines
a domain-level authentication framework for email to permit
verification of the source and contents of messages. This document
specifies an adjunct mechanism to aid in assessing messages that lack
valid DKIM signatures for domains used in the author's address. It
defines a record that can advertise the extent to which a domain
signs outgoing mail that is publicly exchanged on SMTP port 25, as
described in [RFC2821]. Also, how other hosts can access those
records.
Advertisements, defined by this document, may also increase DKIM
signature expectations for messages received by Mail User Agents
(MUAs) or for messages which might have been exchanged over protocols
other than SMTP. In some circumstances, author domains may wish to
have accommodations for protocol failures or for mixed public
protocol messaging not to be made.
In addition, DKIM's identity parameters related to the author address
are decisive only when a corresponding DKIM key local-part template
precludes an author address. DKIM in conjunction with ADSP is to
provide methods for detecting the spoofing of known domains, but not
for making strong assertions about the identity of the message
author.
"Re-direct Mechanism for IKEv2", Vijay Devarapalli, Kilian Weniger, Pasi
Eronen, 14-Jul-08, <draft-devarapalli-ipsec-ikev2-redirect-02.txt>
IKEv2 is a popular protocol for setting up VPN tunnels from a remote
location to a gateway so that the VPN client can access services in
the network behind the gateway. Currently there is no standard
mechanism specified that allows an overloaded VPN gateway to re-
direct the VPN client to attach to another gateway. This document
proposes a re-direct mechanism for IKEv2. The proposed mechanism can
also be used for Mobile IPv6 to enable the home agent to re-direct
the mobile node to another home agent.
"Negotiation of Generic Image Attributes in SDP", Ingemar Johansson, Kyunghun
Jung, 19-Sep-08, <draft-johansson-mmusic-image-attributes-02.txt>
This document proposes a new generic session setup attribute to make
it possible to negotiate different image attributes such as image
size. A possible use case is to make it possible for a e.g a low-end
hand-held terminal to display video without the need to rescale the
image, something that may consume large amounts of memory and
processing power. The draft also helps to maintain an optimal
bitrate for video as only the image size that is desired by the
receiver is transmitted.
"IP Flow Information Accounting and Export Benchmarking Methodology", Jan
Novak, 27-Oct-08, <draft-novak-bmwg-ipflow-meth-01.txt>
This document provides methodology and framework for quantifying
performance implications of enabling selective monitoring of
IP flows on a network device and export of this information to
a collector as specified in [RFC5101].
"Common YANG Data Types", Juergen Schoenwaelder, 14-Jul-08,
<draft-schoenw-netmod-yang-types-01.txt>
This document introduces a collection of common data types to be used
with the YANG data modeling language.
"DKIM Author Domain Signing Practices (ADSP)", agent Local-part, Author
Domain, Jon Callas, John Levine, Ellen Siegel, 23-May-08,
<draft-levine-dkim-adsp-00.txt>
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages. This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address. It defines a
record that can advertise whether they sign their outgoing mail, and
how other hosts can access those records.
"DKIM Third-Party Authorization for Author Domain Signing Practices", Douglas
Otis, 24-May-08, <draft-otis-dkim-tpa-adsp-00.txt>
TPA-label is a DNS-based prefix mechanism for DKIM policy records as
a means to authorize Third-Party domains. This mechanism allows
first-party domains to autonomously authorize a range of third-party
domains in a scalable, individual DNS transaction. This
authorization extends the scope of DKIM policy assertions to supplant
more difficult to administer mechanisms. Alternatives for
facilitating third-party authorizations currently necessitate the
coordination between two or more domains by setting up selector/key
DNS records, DNS zone delegations, or the regular exchange of public/
private keys.
Checking DKIM policies may occur when a From header email-address is
not within the domain of a valid DKIM signature. When a Third-Party
signature is found, TPA-labels offer an efficient means for email
address domains to authorize specific third-party signing domains.
The scope of the authorization may separately assert identity
authentication for From and Sender and Resent-* headers for email-
addresses within the authorizing domain. Identity authentication can
be asserted by the scope of the authorization, even when signed by a
Third-Party domain. In addition, the RFC2821.MailFrom domain can
authorize domains for controlling DSNs.
"Simplified View-based Access Control Model (SVACM) for the Simple Network
Management Protocol (SNMP)", Chunxiu Li, Yan Li, 18-Nov-08,
<draft-li-isms-svacm-01.txt>
This document introduces a Simplified View-based Access Control Model
(SVACM) for the Simple Network Management Protocol (SNMP), which is
useful for the access control application of SNMP protocol.
This document describes the procedure of access control in SVACM with
Remote Authentication Dial In User Service (RADIUS) server for
authorization.
This document also includes a Management Information Base (MIB) for
remotely managing the configuration parameters for SVACM.
"Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)",
Martin Thomson, 26-May-08, <draft-thomson-beep-async-00.txt>
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
framework for the development of application protocols. This
document describes an BEEP feature that enables asynchrony for
individual channels.
"Atom Link Relation: Discuss", Peter Saint-Andre, 27-May-08,
<draft-saintandre-atomlink-discuss-00.txt>
This specification defines a link relation that enables an Atom
document to point to a venue for multi-party discussion of the
document or its primary topic.
"Securing Neighbour Discovery Proxy Problem Statement", Greg Daley,
Jean-Michel Combes, 28-May-08, <draft-daley-csi-sndp-prob-00.txt>
Neighbour Discovery Proxy is used to provide an address presence on a
link from nodes which are no themselves present. It allows a node to
receive packets directed at its address by allowing another device to
neighbour advertise on its behalf.
Neighbour Discovery Proxy is used in Mobile IPv6 and related
protocols to provide reachability from nodes on the home network when
a Mobile Node is not at home, by allowing the Home Agent to act as
proxy. It is also used as a mechanism to allow a global prefix to
span multiple links, where proxies act as relays for neighbour
discovery messages.
Neighbour Discovery Proxy currently cannot be secured using SEND.
Today, SEND assumes that a node advertising an address is the address
owner and in possession of appropriate public and private keys for
that node. This document describes how existing practice for proxy
Neighbour Discovery relates to Secured Neighbour Discovery.
"Location-to-Service Translation Protocol (LoST) Extension:
ServiceListBoundary", Karl Wolf, 28-May-08,
<draft-wolf-ecrit-lost-servicelistboundary-00.txt>
LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and
location information to service contact URIs. If a LoST client wants
to discover available services for a particular location, it will
perform a <listServicesByLocation> query to the LoST server.
However, the response from the LoST server does not give information
about the geographical region, for which the returned service list is
valid. Therefore this document proposes a ServiceListBoundary, in
addition to the ServiceBoundary (which indicates the region a
specific service URL is valid).
"Guidelines to authors and reviewers regarding the IETF review process",
Suresh Krishnan, Pasi Eronen, Eric Gray, 13-Jul-08,
<draft-krishnan-review-process-01.txt>
This document describes the authors' experiences with the IETF review
process and provides guidelines to draft authors and reviewers on how
to effectively participate in it. This document does not define the
IETF review process itself.
"Classification of Location-based Services", Andrea Forte, Henning
Schulzrinne, 28-May-08, <draft-forte-ecrit-service-classification-00.txt>
This document creates a registry for describing the types of services
available at a specific location. The registry is then referenced by
other protocols that need a common set of service terms as protocol
constants. In particular, we define location-based service as either
a point at a specific geographic location (e.g., bus stop) or a
service covering a specific region (e.g., pizza delivery).
"In-Vehicle Routing Requirements in Low Power and Lossy Networks", Ryuji
Wakikawa, Hiroshi Kuwabara, 29-May-08,
<draft-wakikawa-roll-invehicle-reqs-00.txt>
This document presents the routing requirements for in-vehicle low
power and lossy networks. Automobiles are already equipped with
several sensors and devices named Electronic Control Unit (ECU) for
controlling, monitoring and entertainment, etc. For the future in-
vehicle networks, the shift to wireless is desirable due to heavy
weight and volume of cables in vehicles and to be able to efficiently
install devices. However, with the limitation of low power, in-
vehicle network still requires reliability and scalability in nature
of the rolls of ECU. The routing protocol should support the
features of low-power, high-reliability, Subnetting, QoS, Mobility,
etc. This document briefly explains the in-vehicle networks and
ECUs, then discusses the requirements for the future wireless in-
vehicle networks.
"Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08,
<draft-rdem-mukul-jaitly-00.txt>
This document describe an data encryption specification which is
based on random bytes selection of data and random key generation.
This encryption process accepts variable input and the key size is
dependent on the input data. This encryption process does not
depend upon any 128 or 256 fixed block encryption. The mechanism
for encryption is simpler to implement, but gives key complexity
of more than 256 bit encryption.
"Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings",
Jonathan Lennox, Thomas Schierl, Sam Ganesan, 2-Jun-08,
<draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt>
The Real-Time Transport Protocol (RTP) specification defines how
layered encodings can be sent over a layered transmission system. A
source can stripe the progressive layers of a hierarchically
represented signal across multiple RTP sessions, each carried on, for
example, its own multicast group. These layered encodings are given
special treatment in RTP, notably in that the same synchronization
source (SSRC) identifier space is used across the sessions of all
layers.
The RTP protocol specification does not, however, explicitly state
how RTP timestamps are to be used with layered encodings. This
document updates the RTP specification to require that RTP timestamps
for layered encodings be synchronized, i.e. that every layer chooses
the same random initial value for the timestamp.
"Proxy Mobile IPv6 Inter-Technology Handover Issue", Behcet Sarikaya, Frank
Xia, 3-Jun-08, <draft-sarikaya-netlmm-itho-00.txt>
Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility
management protocol, that is, a mobile node does not take part in any
mobility signaling. In inter-technology handovers, mobile node input
is required in moving IP sessions from one interface to the other.
This document discusses the impact of the mobile node involvement
during inter-technology handover.
"Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful", Francis
Dupont, Jean-Michel Combes, Maryline Laurent-Maknavicius, 3-Jun-08,
<draft-dupont-mext-dhaadharmful-00.txt>
The Dynamic Home Agent Address Discovery (DHAAD) mechanism is
described in the Mobile IPv6 specification. This mechanism is
mandatory in any compliant Mobile IPv6 implementation and so in any
MIPv6 based protocols too. On the other hand, DHAAD was the only one
mechanism to discover a potential Home Agent for a Mobile Node in the
past. This is no longer the case today. This document analyzes the
security of the different existing home agent discovery mechanisms
and promotes the remove of DHAAD from the future Mobile IPv6
standard, in light of this security analysis.
"Session Multiplexing for SVC Video", Miska Hannuksela, Ye-Kui Wang,
14-Jul-08, <draft-hannuksela-avt-rtp-svc-01.txt>
This memo describes two alternative methods for decoding order
recovery of the Network Abstraction Layer (NAL) units carried in
multiple RTP sessions for Scalable Video Coding (SVC), which is
defined in Annex G of the ITU-T Recommendation H.264 video codec that
is technically identical to Amendment 3 of ISO/IEC International
Standard 14496-10. The methods apply when non-interleaved
transmission of NAL units using the Single NAL Unit packetization
mode or the Non-Interleaved packetization mode defined in RFC 3984 is
in use.
Table of Contents
Status of this Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................2
"Reserved Top Level DNS Names", Frank Ellermann, Donald Eastlake 3rd,
18-Aug-08, <draft-ellermann-idnabis-test-tlds-12.txt>
To reduce the likelihood of conflict and confusion, a few top level
domain names are reserved for use in private testing, as examples in
documentation, and the like. In addition, a few second level domain
names reserved for use as examples are documented. This memo
replaces RFC 2606 reserving 21 additional TLDs.
"DHCP Reconfigure Extension Option", Vitali Vinokour, Wojciech Dec, James
Bristow, David Miles, 6-Jun-08,
<draft-vinokour-dhcp-reconfigure-option-00.txt>
The current use of DHCP (Dynamic Host Configuration Protocol)
Reconfigure extension is limited by a requirement that FORCERENEW
message is authenticated. This document defines a mechanism allowing
the use of FORCERENEW without DHCP authentication.
"BGP Extended Community Attribute for QoS Marking", Thomas Martin Knoll,
14-Jul-08, <draft-knoll-idr-qos-attribute-02.txt>
This document specifies a simple signalling mechanism for inter-
domain QoS marking using several instances of a new BGP Extended
Community Attribute. Class based packet marking and forwarding is
currently performed independently within ASes. The new QoS marking
attribute makes the targeted Per Hop Behaviour within the IP prefix
advertising AS and the currently applied marking at the peering point
known to all access and transit ASes. This enables individual
(re-)marking and possibly forwarding treatment adaptation to the
original QoS class setup of the respective originating AS. The
attribute provides the means to signal QoS markings on different
layers, which are linked together in QoS Class Sets. It provides
inter-domain and cross-layer insight into the QoS class mapping of
the source AS with minimal signalling traffic.
"BGP ACCEPT_OWN Well-known Community Attribute", James Uttaro, Pradosh
Mohapatra, David Smith, Robert Raszuk, John Scudder, Intellectual Property,
8-Jun-08, <draft-pmohapat-l3vpn-acceptown-community-00.txt>
Under certain conditions it is desirable for a BGP route reflector to
be able to modify the Route Target list of a VPN route that is
distributed by the route reflector, enabling the route reflector to
control how a route originated within one VRF is imported into other
VRFs. This technique works effectively as long as the VRF that
exports the route is not on the same PE as the VRF(s) that import the
route. However, due to the constraints of the BGP protocol, it does
not work if the two are on the same PE.
This document describes a modification to the BGP protocol allowing
this technique to work when the VRFs are on the same PE, allowing the
technique to be used in a standard manner throughout an autonomous
system.
"Clarifying Handling of M & O Flags of IPv6 Router Advertisement", Hyunwook
Cha, Bernie Volz, 8-Jun-08, <draft-cha-ipv6-ra-mo-00.txt>
This document clarifies how clients are supposed to use the RA M & O
flags.
"ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro
Yamaguchi, Hiroyuki Ashida, 31-Oct-08,
<draft-shirasaki-isp-shared-addr-01.txt>
This document defines IPv4 ISP Shared Address to be jointly used
among Internet Service Providers (ISPs). This space is intended to
enable ISPs' continuous IPv4 based operation even after the IPv4
address exhaustion.
"NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4
Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 1-Nov-08,
<draft-bagnulo-behave-nat64-02.txt>
NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and
vice-versa. DNS64 is a mechanism for synthesizing AAAA records from
A records. These two mechanisms together enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs. They also
enable peer-to-peer communication between an IPv4 and an IPv6 node,
where the communication can be initiated by either end using
existing, NAT-traversing, peer-to-peer communication techniques.
This document specifies NAT64, and gives suggestions on how they
should be deployed.
"Display-based Address Sorting for the IMAP4 SORT Extension", Dan Karp,
10-Jun-08, <draft-karp-morg-sortdisplay-00.txt>
This document describes an IMAP protocol extension enabling server-
side message sorting based on the commonly-displayed portion of the
From header.
"IMAP4 Extension for returning STATUS information in extended LIST", Alexey
Melnikov, Timo Sirainen, 10-Jun-08,
<draft-melnikov-imapext-status-in-list-00.txt>
Many IMAP clients display information about total number of messages/
total number of unseen messages in IMAP mailboxes. In order to do
that they are forced to issue a LIST or LSUB command, to list all
available mailboxes, followed by a STATUS command for each mailbox
found. This document provides an extension to LIST command that
allows the client to request STATUS information for mailboxes
together with other information typically returned by the LIST
command.Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
morg@ietf.org.
"A New BGP Standards Action Community, LAST_RESORT", Brian Dickson,
20-Aug-08, <draft-dickson-idr-last-resort-05.txt>
This Internet Draft describes a new Standards Action BGP community,
LAST_RESORT.
This community provides a simple and easily deployable solution to a
certain class of BGP "wedgies".
Initial deployment is expected to be achieved by voluntary use in the
network operator community-at-large.
Long-term adoption via software enforcement of the community, will
improve global behavior, and simplify router configurations.
The Standards Action range of communities (previously limited to the
"well-known" communities) ensures that the expectation of (eventual)
router support is reasonable.
"Additional DNS Resource Records", Randall Atkinson, 11-Jun-08,
<draft-rja-ilnp-dns-00.txt>
This note describes four additional optional Resource
Records for use with the Domain Name System (DNS). At
present these optional resource records are subject of
experimentation in certain IP networks. Limited deployment
is anticipated in the near future.
"IPv6 RADIUS attributes for DHCP based networks", Benoit Lourdelet,
12-Jun-08, <draft-lourdelet-radext-ipv6-dhcp-00.txt>
This document specifies RADIUS [RFC2865] attributes supporting IPv6
network access to complement [RFC3162] in DHCP environments. It
addresses the need to dynamically advertise DNS Server addresses and
one or multiple IPv6 addresses via DHCPv6.
"Nonce Destination Option", Randall Atkinson, 12-Jun-08,
<draft-rja-ilnp-nonce-00.txt>
This document describes an experimental Nonce Destination
Option that could be used as part of an Identifier Locator
Network Protocol (ILNP) that is based upon IPv6.
"GRE key as the traffic selector for IPsec tunnel", Hui Deng, Yuanchen Ma,
Yingzhe Wu, 13-Jun-08, <draft-deng-ipsec-gre-key-ts-00.txt>
This document describes the IPsec Tunnel based on GRE key as the
traffic selector. When GRE key is used in IP packet transmission
scenario of the wireless communication. Several enterprise need
different security policy when transmit the packet through some
unguaranteeded Internet cloudy. This document propose to adopt GRE
key as the IPsec traffic selector.
"The application/opensearchdescription+xml media type", Frank Ellermann,
3-Jul-08, <draft-ellermann-opensearch-01.txt>
This memo defines the application/opensearchdescription+xml media
type for OpenSearch descriptions. Atom and XHTML
<link rel="search" .../> elements are examples where this media type
is used.
"Providing Satellite Navigation Assistance Data using HELD", Martin Thomson,
James Winterbottom, 15-Jun-08, <draft-thomson-held-grip-00.txt>
This document describes a method for providing Global Navigation
Satellite System (GNSS) assistance data using the HTTP-Enabled
Location Delivery (HELD) protocol. An assistance data request is
included with the HELD location request and the Location Information
Server (LIS) provides assistance data along with location
information.
"Neighbor Discovery Registration Extension", Erik Nordmark, 16-Jun-08,
<draft-nordmark-6lowpan-reg-00.txt>
In order to reduce Neighbor Discovery multicast messages it is useful
if the routers on a link can maintain an authoritative list of the
IPv6 and layer 2 addresses for all the hosts on the link.
This draft specifies an extension to the Router Advertisement
messages which trigger to hosts to send periodic registration
messages which can be either unicast, multicast, or anycast. The
protocol uses a soft-state approach to gather registration
information.
"Attention Request (POKE) for Instant Messaging", Gustavo Garcia, Jose-Luis
Martin, 16-Jun-08, <draft-garcia-simple-poke-00.txt>
This document specifies a message content type and XML format to
request attention from a targeted user. This feature is usually
known as poke, nudge or buzz in existing messaging platforms. Its
primary use is as an additional instant messaging capability that can
be sent in the middle of a instant messaging session or in a
standalone message at any time. This message also allows the sender
to indicate the preferred realization of the attention request:
vibrator, light, tone, media or text.
"Requirements for Dialog Correlation in the Session Initiation Protocol
(SIP)", Gonzalo Camarillo, Salvatore Loreto, 20-Oct-08,
<draft-loreto-sipping-context-id-requirements-01.txt>
This document justifies the need and lists the requirements for
correlating SIP (Session Initiation Protocol) dialogs that relate to
the same multimedia session. Being able to logically correlate
multiple SIP dialogs is useful for applications that, for different
reasons, need to establish several SIP dialogs to provide a given
service.
"Conversion parameters for IMAP CONVERT", Alexey Melnikov, 2-Nov-08,
<draft-melnikov-lemonade-convert-params-02.txt>
This is a companion document to the Lemonade CONVERT
(draft-ietf-lemonade-convert-XX.txt) extension. It defines
additional conversion parameters for conversions of image/* and
text/* body parts. It also demonstrates additional CONVERT usage
scenarios.
"Pairtrees for Object Storage (V0.1)", John Kunze, Martin Haye, Erik Hetzner,
Mark Reyes, 17-Jun-08, <draft-kunze-pairtree-00.txt>
This document specifies Pairtree, a filesystem hierarchy for holding
objects that are located by mapping identifier strings to object
directory (or folder) paths two characters at a time. If an object
directory (folder) holds all the files, and nothing but the files,
that comprise the object, a "pairtree" can be imported by a system
that knows nothing about the nature or structure of the objects but
can still deliver any object's files by requested identifier. The
mapping is reversible, so the importing system can also walk the
pairtree and reliably enumerate all the contained object identifiers.
To the extent that object dependencies are stored inside the pairtree
(e.g., fast indexes stored outside contain only derivative data),
simple or complex collections built on top of pairtrees can recover
from index failures and reconstruct a collection view simply by
walking the trees. Pairtrees have the advantage that many object
operations, including backup and restore, can be performed with
native operating system tools.
"BGP Communities use for the prefix origination tagging", Dave Meyer, Matvey
Teplov, 17-Jun-08, <draft-teplov-grow-rfc4384-bis-00.txt>
BGP communities [RFC 1997] are 64-bit values that are used to tag
the originated or traversing prefixes for the different purposes, such as
origination tagging or policy application purposes. These values can be displayed
in a new and old format, which notes different representation of the same
64-bit value. This document defines the way of tagging prefixes based upon
their geographical origination to assist in development of geographically-based
policies that, ideally, will result in RTD (Round Trip Delay) value improvements,
as optimized paths can be established.
"Sender RTT Estimate Option for DCCP", Gerrit Renker, 18-Jun-08,
<draft-renker-dccp-tfrc-rtt-option-00.txt>
This document describes an optional extension for DCCP congestion-
control CCIDs that are based on TCP-Friendly Rate Control (TFRC).
The extension improves the accuracy of parameter estimation at the
TFRC receiver, by periodically communicating the (more precise) RTT
estimate available at the sender.
"Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna,
Oliver Blume, 14-Jul-08, <draft-liebsch-netlmm-transient-bce-pmipv6-01.txt>
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 for inter-MAG handover optimization. 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 a 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.
"HIP support for RFID", Pascal Urien, 18-Jun-08, <draft-urien-hip-tag-00.txt>
This document describes an architecture based on the Host Identity
Protocol (HIP), for active tags, i.e. RFIDs that include tamper
resistant computing resources, as specified for example in the ISO
14443 or 15693 standards. HIP-Tags never expose their identity in
clear text, but hide this value (typically an EPC-Code) by a
particular equation (f) that can be only solved by a dedicated
entity, referred as the portal. HIP exchanges occurred between HIP-
Tags and portals; they are shuttled by IP packets, through the
Internet cloud.
"TLS Key Generation", Pascal Urien, 18-Jun-08,
<draft-urien-tls-keygen-00.txt>
The TLS protocol is widely deployed and used over the Internet.
Client and server nodes compute a set of keys called the key-block,
according to a pseudo random function (PRF). This draft proposes a
keying infrastructure based on the TLS protocol. It suggests
defining an additional Key Distribution Function (KDF) in order to
deliver a set of cryptographic keys. In a peer to peer mode keys are
directly produced as inputs of the KDF functions. For centralized
architectures they are delivered through containers, secured with
keys derived from the KDF function.
"Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro
Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 19-Jun-08,
<draft-arifumi-6man-rfc3484-revise-00.txt>
RFC 3484 has several known issues to be fixed mainly because of the
deprecation of IPv6 site-local unicast address and the coming of ULA.
Additionally, the rule 9 of the destination address selection rules,
namely the longest matching rule, is known for its adverse effect on
the round robin DNS technique. This document covers these essential
points to be modified and proposes possible useful changes to be
included in the revision of RFC 3484.
"Mobile IPv6 Flow Routing over Multiple Care-of Addresses", Michael Eriksson,
Conny Larsson, Romain Kuntz, 19-Jun-08,
<draft-eriksson-mext-mipv6-routing-rules-00.txt>
This document specifies a mechanism to selectively route IP flows to
and from Mobile IPv6 Mobile Nodes and NEMO Mobile Routers which have
registered multiple care-of addresses. It explains how to apply the
generic flow distribution language defined in a companion draft to
Mobile IPv6, defines a transport mechanism to transmit the rules
between Mobile IPv6 nodes, and describes how the rules are sent and
handled upon reception.
"IANA Registration for Location ('loc') Enumservice", Alexander Mayrhofer,
19-Jun-08, <draft-mayrhofer-enum-loc-enumservice-00.txt>
This document requests IANA registration of an Enumservice for
reflecting location information. The Enumservice uses the 'loc' Type
name, and makes use of the proposed 'held' and 'geo' URI schemes.
"Channel binding for HTTP Digest Authentication", Stefan Santesson,
14-Jul-08, <draft-santesson-digestbind-01.txt>
This document specifies a method implemented by Microsoft to add
channel binding capabilities to the http digest protocol defined in
RFC 2617 [2617]
"Multicast tunneling optimization for Mobile IPv4", Hui Deng, 20-Jun-08,
<draft-deng-multimob-mip4-00.txt>
This document provides the solution to optimize the multicast
tunneling in mobile IPv4. This solution will not break the basic bi-
directional tunneling multicast solution of MIPv4. A new multicast
foreign agent works as a proxy node for multiple mobile nodes within
one limit scope. Single tunnel is set up between one home agent and
one mobile foreign agent for single multicast stream. A new
notification message is created for the communication between home
agent and multicast foreign agent. There is no modification on
mobile nodes.
"Stream Control Transmission Protocol (SCTP) Stream Reset", Randall Stewart,
Peter Lei, Michael Tuexen, 20-Jun-08, <draft-stewart-tsvwg-sctpstrrst-00.txt>
Many applications that desire to use SCTP have requested the ability
to "reset" a stream. The intention of resetting a stream is to start
the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed. The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number for the
application to track the message flows. Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero". This documents presents also a method for resetting the
transport sequence numbers and all stream sequence numbers.
"Safe IKE Recovery", Frederic Detienne, Pratima Sethi, Yoav Nir, 6-Aug-08,
<draft-detienne-ikev2-recovery-02.txt>
The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
limitation of not having a means to quickly recover from a stale
state known as dangling Security Associations (SA's) where one side
has SA's that the corresponding party does not have anymore.
This Draft proposes to address the limitation by offering an
immediate, DoS-free recovery mechanism for IKE that can be used in
all failover or post-crash situations.
"Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker,
Scott Rose, 14-Jul-08, <draft-crocker-dnssec-algo-signal-01.txt>
The DNS Security Extensions (DNSSEC) was developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be generated using
different algorithms. Each digital signature added to a response
increases the size of the response, which could result in the
response message being truncated. This draft sets out to specify a
way for validating end-system resolvers to signal to a server which
cryptographic algorithms they prefer in a DNSSEC response by defining
an EDNS option to list a client's preferred algorithms.
"MPLS Generic Associated Channel", Matthew Bocci, David Ward, 20-Jun-08,
<draft-bocci-pwe3-ge-ach-00.txt>
This draft describes a generic associated channel header (GE-ACH)
that provides a control channel associated with an MPLS LSP,
pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085
is generalized to allow a larger set of control channel and OAM
functions to be used to meet the requirements of packet transport and
other applications of MPLS.
"JWT Report on MPLS Architectural Considerations for a Transport Profile",
Stewart Bryant, Loa Andersson, 20-Jun-08,
<draft-bryant-jwt-mplstp-report-00.txt,.pdf>
This RFC archives the report of the IETF - ITU-T Jooint Working Team
(JWT) on the application of MPLS to Transport Networks. The JWT
recommended of Option 1: The IETF and the ITU-T jointly agree to work
together and bring transport requirements into the IETF and extend
IETF MPLS forwarding, OAM, survivability, network management and
control plane protocols to meet those requirements through the IETF
Standards Process. There are two versions of this RFC. An ASCII
version that contains a summary of the slides and a pdf version that
contains the summary and a copy of the slides.
"Distributing a Symmetric Neighbor Discovery Key Using SEND", Frank Xia,
Suresh Krishnan, Wassim Haddad, Jean-Michel Combes, Chunqiang Li, 20-Jun-08,
<draft-xia-csi-symmetric-key-00.txt>
In this document, a method for provisioning a shared key from the
router to the host is defined to protect Neighbor Discovery(ND)
signaling between the router and the host. The host sends a Router
Solicitation(RS) message with ND Shared Key Request Option to the
router. The router encrypts a ND shared key using the host's SEcure
Neighbor Discovery(SEND) public key and sends it back to the host
through a Router Advertisement(RA) message. The host decrypts the ND
shared key using the matching private key. The Neighbor Discovery
shared key is then used for protecting the following Neighbor
Discovery signaling between the router and the host. The Router
Solicitation and Router Advertisement message exchanges are required
to have SEND security.
"Dissemination of flow specification rules implementation report", Robert
Raszuk, Pedro Roque Marques, Craig Labovitz, 21-Jun-08,
<draft-raszuk-idr-flow-spec-impl-00.txt>
This document provides an implementation report for Dissemination of
flow specification rules as defined in draft-ietf-idr-flow-spec-01
The editor did not verify the accuracy of the information provided by
respondents or by any alternative means. The respondents are experts
with the implementations they reported on, and their responses are
considered authoritative for the implementations for which their
responses represent.
"Alternative RPKI Repository Retrieval Mechanism", Terry Manderson, George
Michaelson, 23-Jun-08, <draft-sidr-fetch-00.txt>
This document proposes a mechanism for a relying party to synchronise
a local cache of the RPKI repository using a HTTP retrieval
mechanism.
"A three state extended PCN encoding scheme", T Moncaster, Bob Briscoe,
Michael Menth, 23-Jun-08, <draft-moncaster-pcn-3-state-encoding-00.txt>
Pre-congestion notification (PCN) is a mechanism designed to protect
the Quality of Service of inelastic flows. It does this by marking
packets when traffic load on a link is approaching or has exceeded a
threshold below the physical link rate. This baseline encoding
specified how two encoding states could be encoded into the IP
header. This document specified an extension to the baseline
encoding that enables three encoding states to be carried in the IP
header as well as enabling limited support for end-to-end ECN.
Status
This memo is posted as an Internet-Draft with an intent to eventually
be published as an experimental RFC.
"No Service To This Number Reject Code", David Schwartz, 3-Nov-08,
<draft-schwartz-sipping-nsr-code-01.txt>
This specification discusses a SIP response error code ambiguity that
may exist due to sematic differences between SIP [RFC3261] and TEL
[RFC3966] URIs.
"Optimized MAC Address Operations in VPLS with Redundancy", Yuanlong Jiang,
Yang Yang, 24-Jun-08, <draft-jiang-l2vpn-vpls-mac-operation-00.txt>
The Virtual Private LAN Service (VPLS) Using Label Distribution
Protocol (LDP) Signaling is described in RFC 4762. That document
describes a mechanism called MAC Address Withdrawal to remove or
unlearn MAC addresses which have been dynamically learned in a VPLS
instance. Further work in progress defines an extension to MAC
Address Withdrawal procedure which can greatly restrict the scope of
MAC flushing. This document provides two mechanisms which completely
remove the need for MAC address flushing in VPLS instances. The
mechanisms are MAC address switching and MAC address notification.
"Progress and future development of Flow State Aware standards, and a
proposal for alerting nodes or end-systems on data related to a flow",
jongtae song, John Adams, Jinoo Joung, 24-Jun-08,
<draft-adams-tsvwg-flow-signalling-codepoint-00.txt>
This document describes the work in progress on Flow State Aware
standards activity in the ITU and proposes a new type of control packet
to be identified that can alert downstream or upstream nodes on data
related to an individual flow.
"PW Bonding", Yaakov Stein, Itai Mendelsohn, Ron Insler, 3-Nov-08,
<draft-stein-pwe3-pwbonding-01.txt>
There are times when pseudowires must be transported over physical
links with limited bandwidth. We shall use the term "bonding" (also
variously known as inverse multiplexing, link aggregation, trunking,
teaming, etc.) to mean an efficient mechanism for separating the PW
traffic over several links. Unlike load balancing and equal cost
multipath, bonding makes no assumption that the PW traffic can be
decomposed into distinguishable flows, and thus bonding requires
delay compensation and packet reordering. Furthermore, PW bonding
can optionally track bandwidth constraints in order to minimize
packet loss.
"Trusted plane for routing equipment embedding a tamper-resistant device",
Evren Bulut, Emmanuel Onfroy, 25-Jun-08,
<draft-bulut-ospf-trusted-plane-00.txt>
Due to their critical role in a network, the protection of routing
equipements is crucial, particularly against subversion attacks. For
this purpose, we integrate a trusted plane in the network equipments
related to the routing protocols (e.g. OSPF, BGP, RIP). This
trusted plane is realized by a trusted element embedded or connected
to the network equipment.
"An Alternative Connection Model for the Message Session Relay Protocol
(MSRP)", Staffan Blau, Christer Holmberg, 17-Oct-08,
<draft-blau-simple-msrp-acm-02.txt>
This document defines an alternative connection model for MSRP UAs.
The model differs from the standard MSRP model, as defined in RFC4975
and RFC4976 in the following ways: it uses COMEDIA for TCP connection
establishment, and it allows the usage of SDP in a more conventional
way for conveying endpoint address information. Because of this, the
model also allows for the usage of generic mainstream mechanisms for
NAT traversal, instead of using MSRP relays.
"RTP Payload Format for Geographical Location.", Xavier Marjou, Jean Jestin,
26-Jun-08, <draft-marjou-geopriv-avt-geoloc-00.txt>
This memo presents some use-cases and requirements related to the
real-time transport of geographical location information. It also
defines a Real-time Transport Protocol (RTP) packet payload format to
carry real-time geographical location information.
"On RFC Streams, Headers, and Boilerplates", Leslie Daigle, Olaf Kolkman,
20-Oct-08, <draft-iab-streams-headers-boilerplates-03.txt>
RFC documents contain a number of fixed elements such as the title
page header, standard boilerplates and copyright/IPR statements.
This document describes them and introduces some updates to reflect
current usage and requirements of RFC publication. In particular,
this updated structure is intended to communicate clearly the source
of RFC creation and review.
"IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres,
23-Oct-08, <draft-despres-6rd-02.txt>
IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056)
to enable a service provider to rapidly deploy IPv6 unicast service
to IPv4 sites to which it provides customer premise equipment. Like
6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to
transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service
provider uses an IPv6 prefix of its own in place of the fixed 6to4
prefix. A service provider has used this mechanism for its own IPv6
"rapid deployment": five weeks from first exposure to 6rd principles
to more than 1,500,000 residential sites being provided quasi-native
IPv6, under the only condition that they activate it.
"A Diffserv-TE Implementation Model to dynamically change booking factors
during failure events", Jonathan Newton, Mustapha Aissaoui, JP Vasseur,
27-Jun-08, <draft-newton-mpls-te-dynamic-overbooking-00.txt>
This document discusses the requirements for and describes an
implementation model of Diffserv-TE that allows the booking factors
applied to network resources to be dynamically changed during network
failure events.
"Indicating Non-Availability of Dynamic Updates in the DNS", Joe Abley,
27-Jun-08, <draft-jabley-dnsop-missing-mname-00.txt>
The Start of Authority (SOA) Resource Record (RR) in the Domain Name
System (DNS) specifies various parameters related to the handling of
data in DNS zones. These parameters are variously used by authority-
only servers, caching resolvers and DNS clients to guide them in the
way that data contained within particular zones should be used.
One particular field in the SOA RR is known as MNAME, which is used
to specify the "Primary Master" server for a zone. This is the
server to which Dynamic Updates are sent by clients. Many zones do
not accept updates using the Dynamic Update mechanism, and any such
DNS UPDATE messages which are received provide no usual purpose. For
such zones it may be preferable not to receive updates from clients
at all.
This document proposes a convention by which a zone operator can
signal to clients that a particular zone does not accept Dynamic
Updates.
"Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini,
Samer Salam, Ali Sajassi, Satoru Matsushima, Thomas Nadeau, 27-Jun-08,
<draft-martini-pwe3-iccp-00.txt>
This document specifies an inter-chassis communication protocol
(ICCP) that enables PE redundancy for Virtual Private Wire Service
(VPWS) and Virtual Private LAN Service (VPLS) applications. The
protocol runs within a set of two or more PEs, forming a redundancy
group, for the purpose of synchronizing data amongst the systems. It
accommodates multi-chassis attachment circuit as well as pseudowire
redundancy mechanisms.
"Clarification of sender behaviour in persist condition.", Murali Bashyam,
Mahesh Jethanandani, Anantha Ramaiah, 28-Jun-08,
<draft-ananth-tcpm-persist-00.txt>
This document attempts to clarify the notion of the Zero Window
Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it
clarifies the actions that can be taken on connections which are
experiencing the ZWP condition. The motivation for this document
stems from the belief that TCP implementations strictly adhering to
the current RFC language have the potential to become vulnerable to
Denial of Service (DoS) scenarios.
"Mobility Support in IPv4/v", Zhengming Ma, Qingyu Tan, Zheng Xiang,
30-Jun-08, <draft-ma-mobility-support-ipv4-ipv6-00.txt>
This document specifies a protocol named Mobile IPv4/v6, which allows
mobile nodes to remain reachable while moving in IPv4/v6 mixed
networks. A translation gateway called Mobile IPv4/v6 Translation
Gateway (MIPv4/v6-TG) is introduced in this protocol. MIPv4/v6-TG is
based on NAT-PT gateway and equipped with a newly introduced
application level gateway called MIP-ALG. MIPv4/v6-TG is located
between IPv4 network and IPv6 network. On IPv4 network side,
MIPv4/v6-TG acts as a Mobile IPv4 entity and interacts with other
Mobile IPv4 entities under Mobile IPv4, while on IPv6 network side,
it acts as a Mobile IPv6 entity and interacts with other Mobile IPv6
entities under Mobile IPv6. In MIPv4/v6-TG, Mobile IPv4 entities and
Mobile IPv6 entities are translated with each other. In order to
maintain each of Mobile IP sessions that pass through MIPv4/v6-TG, a
data structure called Mobile IP Table is introduced.
"AtomTriples: Embedding RDF Statements in Atom", Mark Nottingham, Dave
Beckett, 30-Jun-08, <draft-nottingham-atomtriples-00.txt>
This specification describes AtomTriples, a set of Atom extension
elements for embedding RDF statements in Atom documents (both element
and feed), and declaring how they can be derived from existing
content.
"Performance Evaluation of PCE Architectures for Wavelength Switched Optical
Networks", Greg Bernstein, 30-Jun-08,
<draft-bernstein-pce-wson-evaluation-00.txt,.pdf>
In this note a number of PCE architectural and computational options
are evaluated against a medium sized wavelength switched optical
network. The key performance measures of overall and backward
blocking are reported under different dynamic traffic scenarios. The
corresponding reduction in connection blocking probabilities and
computational advantages enabled by these architectural alternatives
strongly warrant their inclusion in continuing PCE WSON work.
"IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 30-Oct-08,
<draft-wbeebee-ipv6-cpe-router-03.txt>
This document recommends IPv6 behavior for Customer Premises
Equipment (CPE) routers in Internet-enabled homes and small offices.
The CPE Router may be a standalone device. The CPE Router may also
be embedded in a device such as a cable modem, DSL modem, cellular
phone, etc. This document describes the router portion of such a
device. The purpose behind this document is to provide minimal
functionality for interoperability and create consistency in the
customer experience and satisfy customer expectations for the device.
Further, the document also provide some guidance for implementers to
expedite availability of IPv6 CPE router products in the marketplace.
"Requirements for Label Edge Router Forwarding of IPv4 Option Packets",
William Jaeger, John Mullooly, Tom Scholl, David Smith, Intellectual
Property, 6-Oct-08, <draft-dasmith-mpls-ip-options-01.txt>
This document imposes a new requirement on Label Edge Routers (LER)
specifying that when determining whether to MPLS encapsulate an IP
packet, the determination is made independent of any IP options that
may be carried in the IP packet header. Lack of a formal standard
may result in a different forwarding behavior for different IP
packets associated with the same prefix-based Forwarding Equivalence
Class (FEC). While an IP packet with either a specific option type
or no header option may follow the MPLS label switched path (LSP)
associated with a prefix-based FEC, an IP packet with a different
option type but associated with the same prefix-based FEC may bypass
MPLS encapsulation and instead be IP routed downstream. IP option
packets that fail to be MPLS encapsulated simply due to their header
options present a security risk against the MPLS infrastructure.
"AES Galois Counter Mode for the Secure Shell Transport Layer Protocol",
Kevin Igoe, Jerome Solinas, 30-Jun-08, <draft-igoe-secsh-aes-gcm-00.txt>
Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. SSH
provides for algorithms that provide authentication , key agreement.
confidentiality and data integrity services. This purpose of this
document is to show how the AES Galois/Counter Mode can be used to
provide both confidentiality and data integrity.
"Certified Pan Formation Protocol", Aroua Biri, 30-Jun-08,
<draft-abiri-cpfp-00.txt>
This draft introduces the Certified PN Formation Protocol (CPFP)
based on the personal public key infrastructure (personal PKI)
concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques
by using ECDH, ECDSA and STS protocols and provides feasible
solutions for key revocation and transitive imprinting.
"Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci,
Alessandro Vinciarelli, 27-Oct-08, <draft-gennai-smime-cnipa-pec-01.txt>
Since 1997, the Italian Laws have recognized electronic delivery
systems as legally usable. After 2 years of technical tests, in
2005 the characteristics of an official electronic delivery
service, named certified electronic mail (in Italian "Posta
Elettronica Certificata") were defined, giving the system legal
value.
Design of the entire system was carried out by the National
Center for Informatics in the Public Administration of Italy
(CNIPA), followed by efforts for the implementation and testing
of the service. The CNIPA has given the Italian National
Research Council (CNR), and in particular The Institute of
Information Science and Technologies at the CNR (ISTI), the task
of running tests on providers of the service to guarantee the
correct implementation and interoperability. This document
describes the certified email system adopted in Italy. It
represents the system as it is at the moment of writing,
following the technical regulations that were written based upon
the Italian Law DPR. November 2, 2005.
"1 + /64s as IPv6 Standard Access Model", Shin Miyakawa, Yasuhiro Shirasaki,
30-Jun-08, <draft-miyakawa-1plus64s-00.txt>
This document proposes the "standard" address assignment scheme for
IPv6 access network which uses RA or DHCPv6 to assign an global IPv6
address to the WAN interface of the CPE and DHCPv6 PD on the upstream
link of CPE to delegate one or more /64 prefixes to the CPE.
"Load Balancing for Mesh Softwires", Clarence Filsfils, Pradosh Mohapatra,
Carlos Pignataro, 1-Jul-08, <draft-pmohapat-softwire-lb-00.txt>
Payloads carried over a Softwire mesh service as defined by BGP
Encapsulation Subsequent Address Family Identifier (SAFI) information
exchange often carry a number of identifiable, distinct flows. It
can in some circumstances be desirable to distribute these flows over
the equal cost multiple paths (ECMPs) that exist in the packet
switched network. Currently, the payload of a packet entering the
Softwire can only be interpreted by the ingress and egress routers.
Thus the load balancing decision of a core router is only based on
the encapsulating header, presenting much less entropy than available
in the payload or the encapsulated header since the Softwire
encapsulation acts in a tunneling fashion. This document describes a
method for achieving comparable load balancing efficiency in a
network carrying Softwire mesh service over Layer Two Tunneling
Protocol - Version 3 (L2TPv3) over IP or Generic Routing
Encapsulation (GRE) encapsulation to what would be achieved without
such encapsulation.
"DHCPv4 bulk lease query", D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan
Kurapati, 1-Jul-08, <draft-dtv-dhc-dhcpv4-bulk-leasequery-00.txt>
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv4 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv4 binding data via TCP.
"Generic Mobility Management Protocol", Hui Deng, 30-Oct-08,
<draft-deng-gmmp-01.txt>
This document discusses the communication protocol between mobile
access point and terminal. With the evolution of mobile
communication, there are various kind of wireless communication
technologies such as WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al.
Each of these wireless communication technology has independent
connection, mobility and configuration management. This document
would like to cover all these functions into a common ground
especially in the environment of multiple connections.
"Extension headers for 6lowpan", Carsten Bormann, 1-Jul-08,
<draft-bormann-6lowpan-ext-hdr-00.txt>
6lowpan applications sometimes need to include application-specific
information in layer 2 packets that are intended to be processed as
6lowpan packets. This document specifies a way to include this
information in a 6lowpan packet in such a way that it can be ignored
by implementations that don't care for it.
$Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo
Exp $
"Common Functions of Large Scale NAT (LSN)", Tomohiro Nishitani, Shin
Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 19-Nov-08,
<draft-nishitani-cgn-01.txt>
This document defines common functions of multiple types of Large
Scale Network Address Translation (NAT) that handles Unicast UDP, TCP
and ICMP.
"Application of Event Package Bodies to Subscriptions to Lists of Resources
in the Session Initiation Protocol (SIP)", Adam Roach, 2-Jul-08,
<draft-roach-sip-list-subscribe-bodies-00.txt>
This document specifies a mechanism by which subscriptions to the
state of request-contained ("ad-hoc") lists of resources can have
event-package-defined bodies applied to each of the contained
resources.
"DHCP Based Configuration of Mobile Node from Home Network", Hui Deng,
2-Jul-08, <draft-deng-mip4-host-configuration-00.txt>
This document describes the mechanism for providing the host
configuration parameters needed for network service from home network
based on DHCPINFORM. DHCPINFORM message has been widely used by
client to obtain other configuration information and could be sent to
local broadcast address or server unicast address. Mobile IP
specification could support DHCPINFORM broadcast or unicast message
straightfully without any revision.
"DKIM Extensions", Phillip Hallam-Baker, 13-Jul-08,
<draft-hallambaker-dkim-extensions-01.txt>
Optional extensions for DKIM are described. A DKIM Policy statement
is defined for the policy 'this zone never sends mail'. The NULL Key
Algorithm is defined to simplify management of large zones where most
mail is signed but with important exceptions. The X509 key record
extension allows the location from which an X.509v3 certificate for
the key specified in the record may be obtained.
"Diameter User-Name and Realm Based Request Routing Clarifications", Jouni
Korhonen, Mark Jones, Lionel Morand, Tina Tsou, 27-Oct-08,
<draft-korhonen-dime-nai-routing-02.txt>
This specification clarifies the Diameter realm based request
routing. We focus on the case where a Network Access Identifier in
the User-Name AVP is used to populate the Destination-Realm AVP and
the Network Access Identifier contains more than one realm. This
particular case is possible when the Network Access Identifier
decoration is used to force a routing of request messages through a
predefined list of realms. However, this functionality is not
unambiguously specified in the Diameter Base Protocol specification.
"Moving the Session Initiation Protocol (SIP) Towards Draft Standard", Robert
Sparks, 2-Jul-08, <draft-sparks-sip-steps-to-draft-00.txt>
This document is intended to stimulate discussion and progress
towards advancing SIP to Draft Standard. It points to some of the
issues the working group will need to work through and proposes an
approach for creating an interoperability statement.
"RFC 2026 in practice", Brian Carpenter, 2-Jul-08,
<draft-carpenter-rfc2026-practice-00.txt>
This document discusses how RFC 2026, the current description of the
IETF standards process, operates in practice. Its main purpose is to
document, for information only, how actual practice interprets the
formal rules.
"Specifying Unsafe Areas in LoST Service Boundary", Qian Sun, Robins George,
2-Jul-08, <draft-sun-ecrit-unsafe-areas-00.txt>
This document describes how to specify unsafe areas in LoST for
emergency services, such as police, mountain, marine and fire.
"Location-to-Service Translation Protocol (LoST) Sub-Services", Robins
George, Qian Sun, 2-Jul-08, <draft-robins-ecrit-sub-services-00.txt>
This document describes, how a LoST client can ask LoST server for
the list of sub services that it supports, and to incorporate
additional information about the service provider in response.
"Providing Satellite Navigation Assistance Data using HELD", Martin Thomson,
James Winterbottom, 2-Jul-08, <draft-thomson-geopriv-held-grip-00.txt>
This document describes a method for providing Global Navigation
Satellite System (GNSS) assistance data using the HTTP-Enabled
Location Delivery (HELD) protocol. An assistance data request is
included with the HELD location request and the Location Information
Server (LIS) provides assistance data along with location
information.
"A Packet Partition Scheduling Mechanism for Bandwidth Aggregation through
Multiple Network Interfaces", Pyung-Soo Kim, Joo-Young Yoon, Han-Lim Kim,
2-Jul-08, <draft-pskim-mext-bagg-scheduling-00.txt>
This draft considers a packet partition scheduling mechanism for
effective bandwidth aggregation over end-to-end multi-path through
multiple network interfaces.
"IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08,
<draft-kaippallimalil-v6ops-ipv6-bbnet-00.txt>
This document describes IPv6 link models and their applicability in a
fixed broadband network architecture. This document also specifies
the addressing and operation of IPv6 in broadband networks. The
scope of this specification is limited to the operation of IPv6 in a
broadband architecture. This includes the IPv6 link model, address
configuration, router and neighbor discovery in broadband
architecture.
"Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", Ted
Hardie, 3-Jul-08, <draft-hardie-p2psip-p2p-pointers-00.txt>
Discovering overlay networks and the resources found within in them
presents a number of bootstrapping problems. While those hard
problems are under discussion, this draft proposes a small set of
mechanisms which are intended to be generically useful for
providing pointers to peer-to-peer overlay networks in web pages,
email messages, and other textual media. While the mechanisms
described below each meet similar needs, they are not mutually
exclusive; it is expected that each will find some useful
deployment during the early days of peer-to-peer overlay
deployment.
"IPv6 in Broadband Networks", John Kaippallimalil, Frank Xia, 3-Jul-08,
<draft-v6ops-kaippallimalil-ipv6-bbnet-00.txt>
This document describes IPv6 link models and their applicability in a
fixed broadband network architecture. This document also specifies
the addressing and operation of IPv6 in broadband networks. The
scope of this specification is limited to the operation of IPv6 in a
broadband architecture. This includes the IPv6 link model, address
configuration, router and neighbor discovery in broadband
architecture.
"Shelter Service And Classification", Qian Sun, Robins George, Henning
Schulzrinne, 29-Oct-08, <draft-sun-ecrit-shelter-service-01.txt>
This document defines and registers a new service 'shelter', for the
service URN to find, what instances of shelter service are closest to
the user's location. The Location-to-Service Translation (LoST)
protocol can provide these information for a geographical region.
"RADIUS Over TCP", Alan DeKok, Intellectual Property, 2-Nov-08,
<draft-dekok-radext-tcp-transport-01.txt>
The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer. This document defines RADIUS over the
Transmission Control Protocol (TCP).
"MPLS-TP Requirements", Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts,
Nurit Sprecher, 31-Oct-08, <draft-jenkins-mpls-mpls-tp-requirements-01.txt>
This document specifies the requirements for a MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International
Telecommunications Union (ITU)-IETF effort to include a MPLS
Transport Profile within the IETF MPLS architecture to support the
capabilities and functionalities of a packet transport network as
defined by International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements, MPLS architecture
as defined by IETF and packet transport networks as defined by ITU-T.
"Extensions to the Path Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Paths", Quintin Zhao,
Daniel King, Fabien Verhaeghe, Tomonori Takeda, Mohamad Chaitou, Jean-Louis
Le Roux, Zafar Ali, 3-Jul-08, <draft-zhao-pcep-p2mp-extension-00.txt>
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first
be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs.
This document describes extensions to the PCE Communication Protocol
PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs.
"Lossless Compression for IP Flow Information Export (IPFIX)", Gerhard Muenz,
Lothar Braun, 3-Jul-08, <draft-muenz-ipfix-compression-00.txt>
In this document, we discuss the benefits and possible realizations
of IPFIX traffic compression. Experiments with real measurement data
show that a significant compression gain can be achieved by applying
the DEFLATE compression method to IPFIX data sets. Compression of
IPFIX traffic can be based on underlying transport protocols, such as
IPComp and TLS/DTLS, or realized as an extension of the IPFIX
protocol.
"MVPN: Optimized use of PIM, Wild Card Selectors, Bidirectional Tunnels,
Extranets", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 31-Oct-08,
<draft-rosen-l3vpn-mvpn-mspmsi-02.txt>
Specifications for a number of important topics were arbitrarily
omitted from the initial MVPN specifications, so that those
specifications could be "frozen" and advanced. The current document
provides some of the missing specifications. The topics covered are:
(a) using Wild Card selectors to bind multicast data streams to
tunnels, (b) using Multipoint-to-Multipoint Label Switched Paths as
tunnels, (c) binding bidirectional customer multicast data streams to
specific tunnels, (d) running PIM (i.e., sending and receiving
multicast control traffic) over a set of tunnels that are created
only if needed to carry multicast data traffic, and (e) extranets.
"Multicast Control Extensions for ANCP", Philippe Champagne, Wojciech Dec,
Sanjay Wadhwa, Stefaan De Cnodder, Roberta Maglione, 3-Jul-08,
<draft-ancp-mc-extensions-00.txt>
This draft is aimed at describing the ANCP protocol extensions
required to support the NAS initiated ANCP Multicast Control use case
described in ANCP framework draft. It proposes the definition of new
ANCP message types, along with well known TLVs.
"MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric
Gray, 8-Oct-08, <draft-gray-mpls-tp-nm-req-01.txt>
This document specifies the network management requirements for
supporting the Transport Profile for Multi-Protocol Label
Switching (MPLS-TP).
Gray, et al
Expires April, 2009
[page 1]
Internet-Draft
MPLS-TP NM Requirements
October, 2008
"Routing and Wavelength Assignment Information Encoding for Wavelength
Switched Optical Networks", Greg Bernstein, 3-Nov-08,
<draft-bernstein-ccamp-wson-encode-01.txt>
A wavelength switched optical network (WSON) requires that certain
key information elements are made available to facilitate path
computation and the establishment of label switching paths (LSPs).
The information model described in "Routing and Wavelength Assignment
Information for Wavelength Switched Optical Networks" shows what
information is required at specific points in the WSON.
The information may be used in Generalized Multiprotocol Label
Switching (GMPLS) signaling protocols, and may be distributed by
GMSPL routing protocols. Other distribution mechanisms (for example,
XML-based protocols) may also be used.
This document provides efficient, protocol-agnostic encodings for the
information elements necessary to operate a WSON. It is intended that
protocol-specific documents will reference this memo to describe how
information is carried for specific uses.
"Routing Metrics used for Path Calculation in Low Power and Lossy Networks",
Mijeom Kim, JP Vasseur, Hakjin Chong, 17-Nov-08,
<draft-mjkim-roll-routing-metrics-02.txt>
This document specifies routing metrics to be used in path
calculation for Routing Over Low power and Lossy networks (ROLL).
Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired networks or even with similar ones
such as mobile ad-hoc networks. By contrast with typical Interior
Gateway Protocol (IGP) routing metrics using hop counts or link
attributes, this document specifies a set of routing metrics suitable
to LLNs.
"ATN Topology Considerations for Aeronautical NEMO RO", Christian Bauer,
Serkan Ayaz, 4-Jul-08, <draft-bauer-mext-aero-topology-00.txt>
The intention of this draft is to provide an overview of the topology
of the Aeronautical Telecommunications Network to help with the
analysis of the possible options of NEMO RO within this context. The
intention is to allow taking the existing NEMO RO solution space
analysis document and cross-check it with the aeronautical
environment presented within this document.
"Updates to Referred-By in the Session Initiation Protocol (SIP).", Nadia
Bishai, Salvatore Loreto, Adamu Haruna, 3-Jul-08,
<draft-loreto-sipping-3892bis-00.txt>
SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header
field. When exploding a SIP MESSAGE request to a pre-defined group
URI and when exploding a SIP INVITE request to an ad-hoc group or to
a pre-defined group URI, the Referred-By header field in the
resulting exploded requests is set to the P-Asserted-Identity header
field or to the From header field. The Referred-By header is only
included if the P-Asserted-Identity header field or From header field
needs to carry another value, e.g. the URI of a pre-defined group, or
a conference focus URI. Since the P-Asserted-Identity header field
may carry up to two values, the Referred-By definition needs to be
extended to allow up to two values as well.
"Framework and Requirements for Virtual Private Multicast Service (VPMS)",
Yuji Kamite, Frederic JOUNAY, Ben Niven-Jenkins, Deborah Brungard, Lizhong
Jin, 31-Oct-08, <draft-kamite-l2vpn-vpms-frmwk-requirements-02.txt>
This document provides a framework and service level requirements for
Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer
2 VPN service that provides point-to-multipoint connectivity for a
variety of Layer 2 link layers across an IP or MPLS-enabled PSN.
This document outlines architectural service models of VPMS and
states generic and high level requirements. This is intended to aid
in developing protocols and mechanisms to support VPMS.
"Management Information Base for the SEcure Neighbor Discovery (SEND)
protocol", Alberto Garcia-Martinez, 4-Jul-08,
<draft-garcia-martinez-sendmib-00.txt>
This memo defines a portion of the Management Information Base (MIB)
for managing the SEND (SEcure Neighbor Discovery) Protocol.
"Management Information Base for Cryptographically Generated Addresses
(CGA)", Alberto Garcia-Martinez, 4-Jul-08,
<draft-garcia-martinez-cgamib-00.txt>
This memo defines a portion of the Management Information Base (MIB)
for managing Cryptographically Generated Addresses (CGA).
"UDP-Encapsulated Transport Protocols", Remi Denis-Courmont, 4-Jul-08,
<draft-denis-udp-transport-00.txt>
This memo defines modified formats for conveyance of TCP and SCTP
packets within UDP datagrams, to ease traversal of network address
translators.
"Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian
Kiesel, Laird Popkin, Stefano Previdi, Richard Woundy, Yang Yang, 3-Nov-08,
<draft-kiesel-alto-reqs-01.txt>
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. These recommendations 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 an initial set of requirements for ALTO and
solicits feedback and discussion.
"P2P Traffic Localization by Traceroute and 2-Means Classification", Yunfei
Zhang, Liufei Wen, 14-Jul-08, <draft-zhang-alto-tracerout-01.txt>
Most P2P system performance suffers from the mismatch between the
randomly constructed overlays topology and the underlying physical
network topology, causing a large burden in the ISP and a long RTT
time. This document describes how DHT overlay peers can interact with
the routers by traceroute to get the path information, and execute 2-
Means Classification, thereafter peers leverage the DHT itself to
build efficient "closer" cluster. This scheme only requires the
infrastructure to enable traceroute queries.
"A Fast Handover Scheme in Proxy Mobile IPv6", Youn-Hee Han, Byungjoo Park,
4-Jul-08, <draft-han-netlmm-fast-pmipv6-00.txt>
This memo proposes a scheme that supports a fast handover effectively
in Proxy Mobile IPv6 by optimizing the associated data and signaling
flows during the handover. New signaling messages, Fast PBU and
Reverse PBU, are defined and utilized to expedite the handover
procedure.
"Location Routing Function Requirements", Hadriel Kaplan, 4-Jul-08,
<draft-kaplan-drinks-lrf-requirements-00.txt>
This document describes the requirements for a Location Routing
Function Protocol, for inter and intra-domain SIP session routing.
"A Survey on Research on the Application-Layer Traffic Optimization (ALTO)
Problem", Volker Hilt, Ivica Rimac, Marco Tomsu, Vijay Gurbani, Enrico
Marocco, 4-Jul-08, <draft-hilt-alto-survey-00.txt>
A significant part of the Internet traffic today is generated by
peer-to-peer (P2P) applications used traditionally for file-sharing,
and more recently for real-time communications and live media
streaming. Such applications discover a route to each other through
an overlay network with little knowledge of the underlying network
topology. As a result, they may choose peers based on information
deduced from empirical measurements, which can lead to suboptimal
choices. We refer to this as the Application Layer Traffic
Optimization (ALTO) problem. In this draft we present a survey of
existing literature on discovering topology characteristics.
"The RKEY DNS Resource Record", Jim Reid, Jakob Schlyter, Ben Timms,
4-Jul-08, <draft-reid-dnsext-rkey-00.txt>
A DNS Resource record which can be used to encrypt NAPTR records is
described in this document.
"Scope-Extended Router Advertisement for Connected MANETs", Jaehwoon Lee,
Sanghyun Ahn, Younghan Kim, 28-Oct-08, <draft-jaehwoon-autoconf-sera-01.txt>
In the connected MANET, the MANET Border Router (MBR) is used to
connect the MANET with the external network and MANET nodes are
required to know the MBR address to communicate with hosts in the
external network. One way of acquiring the MBR address is to use the
Router Advertisement (RA) and the Router Solicitation (RS) messages.
In order to allow RA/RS messages to be delivered in the multi-hop
MANET, the modified RA/RS message has been defined [4]. However,
this approach may incur the duplicate packet reception problem due
to rebroadcasting of received RA/RS messages to its neighbors.
In this draft, we define the scope-extended Router Advertisement/
Solicitation message for announcing/solicitating the MBR address in
the connected MANET. In the scope-extended RA/RS message, a new
message field, the sequence number field, is defined so that
duplicate RA/RS messages can be detected based on the sequence
number and the MBR address included in the message.
"P2P Traffic Localization by Alias Tracker for Tracker-based P2P applications
(ATTP)", Yunfei Zhang, Hongluan liao, Naibao ZHOU, 22-Oct-08,
<draft-zhang-alto-attp-02.txt>
Currently P2P applications have accounts for large cross-ISP traffic.
This document proposes a method to reduce cross-ISP traffic by
setting cooperative ISP-friendly trackers in the ISP's network.
Through improving the random node selection mechanism in P2P
tracker-based application, we can effectively reduce cross-ISP
traffic as well as the cost of network equipments and network
operation.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"Cellular-based Central Control (CCC) Mechanism for Mobile Ad hoc Networks",
Yunfei Zhang, 4-Jul-08, <draft-zhang-manet-ccc-00.txt>
This document discusses a cellular based central control
mechanism(CCC) for middle/small scale mobile Ad hoc networks. The
proposed mechanism can be used for the mobile operators to build a
central-controlled and manageable mobile Ad hoc network.
"Lightweight DHCPv6 Relay Agent (LDRA)", David Miles, Sven Ooghe, Wojciech
Dec, Suresh Krishnan, Alan Kavanagh, 18-Nov-08,
<draft-miles-dhc-dhcpv6-ldra-02.txt>
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.
"Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 4-Jul-08,
<draft-jiang-dhc-secure-dhcpv6-00.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.
"Address Autoconfiguration for the subordinate MANET with Multiple MBRs",
Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, 28-Oct-08,
<draft-jaehwoon-autoconf-mmbr-01.txt>
In order to allow the subordinate MANET to be connected to the
external network, the MANET border router (MBR) has been defined. For
providing scalability and reliability to the subordinate MANET,
multiple MBRs may be deployed. One of the issues on the subordinate
MANET with multiple MBRs is which network prefixes are to be
advertised by MBRs. In the case when MBRs advertise different network
prefixes, if a MANET node changes its default MBR to a new one, the
node may have to transmit packets via non-optimal paths to keep using
the existing connection to the previous MBR, or change its address by
using the network prefix information from the new MBR. In the latter
case, on-going sessions can be terminated because of the address
change. In this draft, we define a PMIPv6 based address
autoconfiguration mechanism that enables MANET nodes to operate
properly when all MBRs advertise the same network prefix in the
subordinate MANET.
"SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol",
Michael Tuexen, Irene Ruengeler, Randall Stewart, 5-Jul-08,
<draft-tuexen-tsvwg-sctp-sack-immediately-00.txt>
This document defines a method for a sender of a DATA chunk to
indicate that the corresponding SACK chunk should be sent back
immediately.
"Design Considerations for Session Initiation Protocol (SIP) Overload
Control", Volker Hilt, 5-Jul-08, <draft-hilt-sipping-overload-design-00.txt>
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document discusses models and design considerations for a SIP
overload control mechanism.
"Sieve Extension for converting messages before delivery", Alexey Melnikov,
Qian Sun, 5-Jul-08, <draft-melnikov-sieve-convert-00.txt>
This document describes how Lemonade CONVERT can be used to transform
messages before final delivery.
"RSVP-TE based impairments collection mechanism", Zafar Ali, University
Milan, University Milan, Cisco Systems, University Milan, University Milan,
University Milan, 2-Nov-08,
<draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt>
The problem of path validation of a pure light-path in a Dense
Wavelength Division Multiplexing (DWDM) optical network
requires the transmission of optical impairments related
parameters along the provisioned route. In this draft we
propose an RSVP-TE based mechanism to collect and evaluate
optical impairments measured over optical nodes along the
light-path.
"Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6
Coexistence and Transition", Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang,
Jianping Wu, 5-Jul-08, <draft-xli-behave-ivi-00.txt>
This document presents the concept and practice of the prefix-
specific and stateless address mapping mechanism (IVI) for IPv4/IPv6
coexistence and transition. In this scheme, subsets of the IPv4
addresses are embedded in prefix-specific IPv6 addresses and these
IPv6 addresses can therefore communicate with the global IPv6
networks directly and can communicate with the global IPv4 networks
via stateless (or almost stateless) gateways. The IVI scheme
supports the end-to-end address transparency, incremental deployment
and performance optimization in multi-homed environment. This
document is a comprehensive report on the IVI design and its
deployment in large scale public networks. Based on the IVI
scenario, the corresponding address allocation and assignment
policies are also proposed.
"FIB Suppression with Virtual Aggregation and Default Routes", Paul Francis,
Xiaohu Xu, Hitesh Ballani, 15-Sep-08, <draft-francis-idr-intra-va-01.txt>
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. This document specifies two styles of FIB
suppression. Edge suppression (ES) allows ISPs that deploy a core-
edge topology to shrink the FIBs of their edge routers, including
those that interface to other ISPs and exchange the full DFRT.
Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and
all routers. Both styles may be deployed autonomously by an ISP
(cooperation between ISPs is not required), and can co-exist with
legacy routers in the ISP.
"The WARC File Format (Version 0.16)", Sven Arvidson, John Kunze, Gordon
Mohr, Michael Stack, 5-Jul-08, <draft-kunze-warc-00.txt>
The WARC (Web ARChive) format specifies a method for combining
multiple digital resources into an aggregate archival file together
with related information. Resources are dated, identified by URIs,
and preceded by simple text headers. By convention, files of this
format are named with the extension ".warc" and have the MIME type
application/warc. The WARC file format is a revision and
generalization of the ARC format used by the Internet Archive to
store information blocks harvested by web crawlers. This document
specifies version 0.16 of the WARC format.
"Graceful Shutdown of LDP Adjacency", Siva Sivabalan, Kamran Raza, Sami
Boutros, Bob Thomas, Kenji Kumaki, 3-Nov-08,
<draft-boutros-mpls-ldp-gs-adj-01.txt>
This document specifies an extension to Label Distribution Protocol
(LDP) using which a Label Switched Router (LSR) can explicitly notify
its neighbor LSR its intention to shutdown one or more LDP
adjacencies. This extension shall be used to shutdown LDP adjacencies
for planned maintenance without interrupting traffic.
"The Model for Net and App Interaction", Ray Aatarashi, Megumi Ninomiya,
2-Nov-08, <draft-atarashi-netappmodel-01.txt>
This document describes the model for application and network
interaction in reaction to Application Area Architecture Workshop
held on February 11 and 12, 2008. There is not completed mechanism
for collaboration between application and network yet even though a
solution is required. The model proposed in this document is
designed without a layer violation.
"The VLAN Model for Applications", Megumi Ninomiya, Ray Aatarashi, 2-Nov-08,
<draft-ninomiya-netappvlan-01.txt>
This document describes the model for application and network
interaction in reaction to Application Area Architecture Workshop
held on February 11 and 12, 2008. There is not completed mechanism
for collaboration between application and network yet even though a
solution is required. The model proposed in this document is
designed without a layer violation. This document propose the VLAN
model for the application users.
"NETCONF DSDL and Yang Mapping", Ladislav Lhotka, Rohan Mahy, Sharon
Chisholm, 3-Nov-08, <draft-lhotka-yang-dsdl-map-01.txt>
This draft describes the algorithm and rules for defining NETCONF
data modelss using Document Schema Definition Languages (DSDL) with
additional annotations and based on a mapping from YANG.
"Using EAP-GTC for Simple User Authentication in IKEv2", Yaron Sheffer,
6-Jul-08, <draft-sheffer-ikev2-gtc-00.txt>
Despite many years of effort, simple username-password authentication
is still prevalent. In many cases a password is the only credential
available to the end user. IKEv2 uses EAP as a sub-protocol for user
authentication. This provides a well-specified and extensible
architecture. To this day EAP does not provide a simple password-
based authentication method. The only existing password
authentication methods either require the peer to know the password
in advance (EAP-MD5), or are needlessly complex when used within
IKEv2 (e.g. PEAP). This document codifies the common practice of
using EAP-GTC for this type of authentication, with the goal of
achieving maximum interoperability. The various security issues are
extensively analyzed.
"IKEv2 based Mobile Network Prefix Assignment", Fan Zhao, Stefano Faccin,
Ameya Damle, 6-Jul-08, <draft-zhao-mext-mnp-ikev2-00.txt>
This document proposes a mechanism for the Mobile Router to
dynamically obtain the Mobile Network Prefix through IKEv2. The
mechanisms to renew, release and update the allocated Mobile Network
Prefixes are also described.
"Using EAP keying material to derive keys for DHCP Authentication", Joseph
Salowey, Richard Pruss, 6-Jul-08, <draft-salowey-dhc-eapkey-3118-00.txt>
This memo describes a mechanism to use keying material derived from
the extensible authentication protocol (EAP) to derive cryptographic
keys for authentication of the Dynamic Host Configuration Protocol
(DHCP). Keys are derived from the EAP extended master session key
(EMSK) and are used in a new DHCP authentication option based on the
DHCP delayed authentication option defined in RFC 3118.
"Problem Statement and Requirements for Diameter/Radius Prefix Authorization
Application", Behcet Sarikaya, Frank Xia, 6-Jul-08,
<draft-sarikaya-dimeradext-prefix-auth-ps-00.txt>
This document provides problem statement for AAA prefix authorization
application. The document also identifies application scenarios and
requirements on AAA prefix authorization application.
"The References Header for SIP", Dale Worley, 6-Jul-08,
<draft-worley-references-00.txt>
This document defines a SIP extension header, References, to be used
within SIP messages to signify that the message (and by extension,
the dialog containing it) is related to one or more other dialogs.
It is expected to be used largely for diagnostic purposes.
"Practical Request for BGP Specification and Implementation", Yasuhiro Ohara,
Kenichi Nagami, Akira Kato, 6-Jul-08,
<draft-ohara-idr-practical-request-00.txt>
In 2007, a large scale incident have occurred multiple ISPs where a
number of BGP sessions were disconnected. This happened because of
the different implementation of BGP error handling. Therefore, it is
necessary to classify the error processing of BGP to achieve stable
operation of BGP, and to define it clearly. This document describes
to clarify the classification of BGP error handlings.
"Common TCP Evaluation Suite", Lachlan Andrew, Sally Floyd, 6-Jul-08,
<draft-irtf-tmrg-tests-00.txt>
This document presents an evaluation test suite for the initial
evaluation of proposed TCP modifications. The goal of the test suite
is to allow researchers to quickly and easily evaluate their proposed
TCP extensions in simulators and testbeds using a common set of well-
defined, standard test cases, in order to compare and contrast
proposals against standard TCP as well as other proposed
modifications. This test suite is not intended to result in an
exhaustive evaluation of a proposed TCP modification or new
congestion control mechanism. Instead, the focus is on quickly and
easily generating an initial evaluation report that allows the
networking community to understand and discuss the behavioral aspects
of a new proposal, in order to guide further experimentation that
will be needed to fully investigate the specific aspects of a new
proposal.
"Path and Session Management in Proxy Mobile IPv6", Rajeev Koodli, Julien
Laganier, 6-Jul-08, <draft-koodli-netlmm-path-and-session-management-00.txt>
In a distributed network environment such as a Proxy Mobile IPv6
domain, it is often necessary to know that a peer is alive and, if
not, detect quickly that a peer has failed and subsequently re-
started. It is also necessary to detect failures where only a subset
of the existing mobility sessions are affected. Furthermore, failure
indication should be possible without waiting for an explicit query
from a peer. This document outlines a protocol to address such path
and session reliability for Proxy Mobile IPv6.
"NAT for IPv6-Only Hosts", Cullen Jennings, 3-Nov-08,
<draft-jennings-behave-nat6-01.txt>
This specification defines a NAT that allows IPv6-only hosts that are
inside the NAT to operate with IPv4 hosts that are outside the NAT.
It requires no modifications to the v4 hosts or applications, or to
the operating system of v6 hosts, but it does require some changes to
v6 applications. Typically this specification would be used to allow
the hosts inside a NAT to connect to hosts outside it; but under some
limitations, it can also allow hosts outside to connect to hosts
inside.
The goal of this draft is to consider what is the minimal feasible
approach to this problem. The current intention is to merge this
with the nat64 draft. This draft is being discussed on the
behave@ietf.org list.
"DNS SRV Records for HTTP", Cullen Jennings, 6-Jul-08,
<draft-jennings-http-srv-00.txt>
This document specifies a mechanism for an HTTP client to perform a
DNS SRV lookup to find an HTTP server.
The draft is being discussed on the apps-discuss@ietf.org list.
"HTTP API for Updating DNS Records", Cullen Jennings, Tom Daly, Jeremy
Hitchcock, 3-Nov-08, <draft-jennings-app-dns-update-01.txt>
This specification defines a simple HTTP based scheme for clients to
update DNS records.
The draft is being discussed on the apps-discuss@ietf.org list.
"Multicast Routing Blackhole Avoidance", Rajiv Asati, Mike McBride, 6-Jul-08,
<draft-asati-pim-multicast-routing-blackhole-avoid-00.txt>
This document specifies a mechanism to avoid blackholing of IP
Multicast traffic due to the disruption of multicast tree during the
time when the RPF neighbor is yet to become the PIM neighbor. Such
scenario is possible during the topology change (e.g. link UP) in an
IP network that employs PIM-SM (or SSM) as the multicast routing
protocol and a unicast routing protocol (including static routing).
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"P2P Traffic Localization by Traceroute and 2-Means Classification", Yunfei
Zhang, Liufei Wen, 23-Oct-08, <draft-zhang-alto-traceroute-02.txt>
Most P2P system performance suffers from the mismatch between the
randomly constructed overlays topology and the underlying physical
network topology, causing a large burden in the ISP and a long RTT
time. This document describes how DHT overlay peers can interact with
the routers by traceroute to get the path information, and execute 2-
Means Classification, thereafter peers leverage the DHT itself to build
efficient "closer" cluster. This scheme only requires the infrastructure
to enable traceroute queries.
"Effects of port randomization with TCP TIME-WAIT state.", Anantha Ramaiah,
Patrick Tate, 6-Jul-08, <draft-ananth-tsvwg-timewait-00.txt>
Source port randomization has been suggested to provide improved
security and obfuscation which helps in adding robustness towards
blind attacks. With TCP in practice, simply producing a random port
as the source port for a new connection can lead to problems when a
TCP client establishes connections to a TCP server at a high rate.
If the same source port value is chosen twice, the client TCP
connection can fail due to the server having the Transmission Control
Block (TCB) for this tuple lingering in TIME-WAIT state.
This memo discusses the ramifications of such source port reuse
scenarios and suggests some mitigations to avoid the same.
"GMPLS RSVP-TE recovery extension for data plane initiated reversion", Attila
Takacs, Benoit Tremblay, 3-Nov-08, <draft-takacs-ccamp-revertive-ps-02.txt>
GMPLS RSVP-TE recovery extensions are specified in [RFC4872] and
[RFC4873]. Currently these extensions cannot signal request for
revertive protection neither values for the associated timers to the
remote endpoint. This document defines two new fields in the
PROTECTION Object to specify wait-to-restore and hold-off intervals.
"A Presence Information Data Format - Location Object Extension for
Triangulation Data", James Polk, 6-Jul-08,
<draft-polk-geopriv-pidf-lo-ext-4-triangulation-00.txt>
This document describes how a Presentity Agent (PA) provides a
Location Information Server (LIS) with location specific measurement
data it observes, for example - how many satellites are visible to a
PA, and at what angle are each currently, to aid the LIS in
determining geographically where the PA is. This is done within a
Session Initiation Protocol subscription framework where the LIS
subscribes to the PA for its measurement data. The LIS performs the
location calculation, determining where the PA is.
"Extending the Presence Information Data Format - Location Object (PIDF-LO)
for Assisted Global Positioning System (A-GPS) Data", James Polk, Jay Iyer,
6-Jul-08, <draft-polk-geopriv-pidf-lo-4-agps-00.txt>
This document defines how a device encapsulates Assisted Global
Positioning System (A-GPS) data to ask a Location Information Server
(LIS) to calculate the device's position, and return that
information to the device. This communication will be completed
using the Session Initiation Protocol (SIP), using Presence Filters
specific to A-GPS in a (SUBSCRIBE) request, and a Presence
Information Data Format - Location Object (PIDF-LO) as the (NOTIFY)
reply.
"Session Initiation Protocol (SIP) Location Get Function", James Polk,
6-Jul-08, <draft-polk-sip-location-get-00.txt>
This document defines how a watcher seeks the geographic location
information from presentity. SIP Location Conveyance defines how
location is sent from one entity to another unsolicited. This
document specifies how a watcher, i.e., a Location Target, requests
for specific geolocation state information of a presentity, in
addition to the details within the subscription such as the format
(geo or civic) returned and the frequency of updated location from
the presentity.
"Sensor Network Routing Requirements of Structural Health Monitoring", Jaakko
Hollmen, Jukka Manner, 6-Jul-08, <draft-manner-roll-shm-requirements-00.txt>
This document discusses monitoring the status of constructions,
structural health monitoring, using sensor networks, and the
requirements such a system puts on routing.
"Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali,
3-Nov-08, <draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt>
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label
Switched Paths (TE LSPs) may be established using signaling
techniques described in [RFC4875]. However, [RFC4875] does not
Expires May 2009
[page 1]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
address many issues that comes when a P2MP-TE LSP is signaled in
a multi-domain networks. Specifically, one of the issues in
multi-domain networks is how to allow computation of a loosely
routed P2MP-TE LSP such that it is remerge free. This document
provides a framework and required protocol extensions needed for
establishing and controlling P2MP MPLS and GMPLS TE LSPs in
multi-domain networks.
This document borrows inter-domain TE terminology from
[RFC4726], e.g., for the purposes of this document, a domain
is considered to be any collection of network elements within
a common sphere of address management or path computational
responsibility. Examples of such domains include Interior
Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"Requirements for IP Multicast Session Announcement in the Internet", Hitoshi
Asaeda, Vincent Roca, 6-Jul-08,
<draft-asaeda-mboned-session-announcement-req-00.txt>
The Session Announcement Protocol (SAP) [3] was used to announce
information for all available multicast sessions to the prospective
receiver in an experimental network. It is usefull and easy to use,
but difficult to control the SAP message transmission in a wide area
network. This document describes the several major limitations SAP
has and the requirement of multicast session announcement in the
global Internet.
"PIM/GRE Based MVPN Deployment Experience and Recommendations", Rahul
Aggarwal, Yakov Rekhter, 6-Jul-08, <draft-rekhter-mboned-mvpn-deploy-00.txt>
Multicast VPN, based on the Virtual Router model using PIM with GRE
tunnels, has been in operation in production networks for several
years. This document describes some of the experiences gained from
implementation and deployment of such Multicast VPNs. Further it
describes the practices used by such deployments based on the
experience.
"Meta-Architecture : A Common Means to Accommodate Heterogeneous Network
Architectures", Myung-Ki Shin, Eun Paik, JinHyeock Choi, 7-Jul-08,
<draft-shin-virtualization-meta-arch-00.txt>
The today's Internet architecture is under serious reconsideration
and people started thinking about alternatives. Redefining Internet
architecture requires many challenged works and a lot of new
heterogeneous architectures suited to the future of the Internet
would be considered. It is necessary to support a variety of the new
different architectures to accommodate the heterogeneity of Future
Internet. So, a common means should be provided to accommodate the
new heterogeneous architectures. This document presents Meta-
Architecture to accommodate heterogeneous and diverse multiple
network architecture and user services, for example, heterogeneous
wireless, mobile, sensor, vehicular and/or ad-hoc architectures and
services.
"SIP SAML Profile and Binding", Andreas Pashalidis, Joao Girao, 7-Jul-08,
<draft-pashalidis-sip-saml-00.txt>
This document specifies the SIP/SAML profile and binding, i.e. a
protocol for the use of Security Assertion Markup Language (SAML)
assertions for the purposes of authentication and the exchange of
attributes in a Session Initiation Protocol (SIP) environment.
"TWAMP Reflect Padding Feature", Al Morton, Len Ciavattone, 7-Jul-08,
<draft-morton-ippm-twamp-reflect-padding-00.txt>
The IETF is completing its work on TWAMP - the Two-Way Active
Measurement Protocol. This memo describes a proposed feature for
TWAMP, intended for discussion in the IP Performance Metrics WG. The
feature gives the reflector the ability to return some of the packet
padding bits to the sender.
"Multicast Pruning in Provider Backbone Bridged VPLS", Ali Sajassi, Luyuan
Fang, Pradosh Mohapatra, Nabil Bitar, Raymond Zhang, 7-Jul-08,
<draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt>
The scalability of H-VPLS (either with MPLS or Ethernet access
network) can be improved by incorporating Provider Backbone Bridge
(PBB) functionality in VPLS access.
The ingress replication of PBB multicast traffic can be further
improved by replicating such traffic over a subset of PWs for which
there are receivers interested in that PBB multicast group.
This document discusses the use of BGP for distribution of PBB
multicast addresses (e.g., auto-discovery of these addresses) and
applying multicast pruning to a VPLS instance for efficient ingress
replication.
"Multiprotocol Label Switching Transport Profile Survivability Framework",
Nurit Sprecher, Adrian Farrel, Vach Kompella, 7-Jul-08,
<draft-sprecher-mpls-tp-survive-fwk-00.txt>
Network survivability is the network's ability to restore traffic
following failure or attack; it plays a critical factor in the
delivery of reliable services in transport networks. Guaranteed
services in the form of Service Level Agreements (SLAs) require a
resilient network that detects facility or node failures, very
rapidly, and immediately starts to restore network operations in
accordance with the terms of the SLA.
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a
packet transport technology that combines the packet experience of
MPLS with the operational experience of SONET/SDH. It provides
survivability mechanisms such as protection and restoration, with
similar function levels to those found in established transport
networks such as in SONET/SDH networks. Some of the MPLS-TP
protection mechanisms are data plane-driven and are based on MPLS-TP
OAM fault management functions which are used to trigger protection
switching in the absence of a control plane. Other protection
mechanisms utilize the MPLS-TP control plane.
This document provides a framework for MPLS-TP survivability.
"Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark
Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 3-Nov-08,
<draft-kinnear-dhc-dhcpv4-bulk-leasequery-01.txt>
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a requestor to
request information about DHCPv4 bindings. That mechanism is limited
to queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This
document expands on the DHCPv4 Leasequery protocol to allow for bulk
transfer of DHCPv4 address binding data via TCP.
"Rich Template Set Extension to the IPFIX Protocol", Christoph Sommer, Falko
Dressler, Gerhard Muenz, 7-Jul-08, <draft-sommer-ipfix-richtemplate-00.txt>
This draft describes the Rich Template Set, a Template Set for the
IPFIX Protocol, as well as its respective Template Records. One
possible application domain for this new Set is the transport of
IPFIX Flow Mediation selection criteria. In comparison to the use of
Common Properties, the use of Rich Template Sets reduces the overhead
of repeated transmissions and makes data transmissions more robust
against failures.
"Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide
Koide, Sri Gundavelli, Ryuji Wakikawa, 3-Nov-08,
<draft-glenn-netlmm-pmipv6-mib-01.txt>
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 node
and the local mobility anchor functions of a Proxy Mobile IPv6
(PMIPv6) entity.
"New Care-of CGA Configuration for FMIPv6", David Hu, Chunqiang Li, 7-Jul-08,
<draft-li-mipshop-fmipv6-ncoa-cgaconfig-00.txt>
Fast Mobile IPv6 defines the necessary IP protocol messages to reduce
the handover latency resulting from the Mobile IPv6 procedures. One
of the important functionality is new care-of address configuration.
This document introduces two possible methods for configuring NCoA
based on CGA in FMIPv6.
"IKEv2 SA Synchronization for session resumption", Yan Xu, Peng Yang,
Yuanchen Ma, Hui Deng, Hui Deng, 7-Oct-08, <draft-xu-ike-sa-sync-01.txt>
It will take a long time and mass computation to do session
resumption among IKE/IPsec gateways possibly maintaining huge numbers
of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded.
The major reason is that the prcocedure of IKEv2 SA re-establishment
will incur a time-consuming computation especially in the Diffie-
Hellman exchange. In this draft, a new IKE security associations
synchronization solution is proposed to do fast IKE SA session
resumption by directly transferring the indexed IKE SA (named stub)
from old gateway to new gateway, wherein the most expensive Diffie-
Hellman calculation can be avoided. Without some time-consuming
IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption
procedures can be finished in a short time.
"Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno,
15-Jul-08, <draft-kato-tls-rfc4132bis-02.txt>
This document specifies set of cipher suites to the Transport Layer
Security (TLS) protocol to support the Camellia encryption algorithm
as a block cipher algorithm. This proposal provides options for fast
and efficient block cipher algorithms.
"A Handover Authentication based on AAA server in FMIPv6", Jaeduck Choi,
Doohwan Kim, Souhwan Jung, 7-Jul-08,
<draft-choi-mipshop-handover-authentication-aaa-00.txt>
This document describes a handover authentication protocol based on
the AAA server in FMIPv6. The proposed scheme employs the Diffie-
Hellman (DH) algorithm to enhance security aspects, and modifies the
DH key exchange to reduce computational cost at the Mobile Node (MN)
by delegating exponential operation to the AAA server. The MN and
Access Router (AR) establish the handover key HK through the AAA
server. The main advantage of this document is more secure and
suitable to a light-weight mobile terminal.
"The Extended GSS-API Negotiation Mechanism (NEGOEX)", Larry Zhu, Kevin
Damour, Dave McPherson, 14-Jul-08, <draft-zhu-negoex-01.txt>
This document defines the Extended Generic Security Service
Application Program Interface (GSS-API) Negotiation Mechanism
(NegoEx). NegoEx is a pseudo-security mechanism that logically
extends the SPNEGO protocol as defined in RFC4178.
The NegoEx protocol itself is a security mechanism negotiated by
SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY
adds a pair of meta-data messages for each negotiated security
mechanism. The meta-data exchange allows security mechanisms to
exchange auxiliary information such as trust configurations, thus
NegoEx provides additional flexibility than just exchanging object
identifiers in SPNEGO.
NegoEx preserves the optimistic token semantics of SPNEGO and applies
that recursively. Consequently a context establishment mechanism
token can be included in the initial NegoEx message, and NegoEx does
not require an extra round-trip when the initiator's optimistic token
is accepted by the target.
Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a
security mechanism MUST support in order to be negotiated by NegoEx.
This document defines these GSS-API extensions.
Unlike SPNEGO however, NegoEx defines its own way for signing the
protocol messages in order to protect the protocol negotiation. The
NegoEx message signing or verification can occur before the security
context for the negotiated real security mechanism is fully
established.
"Problem Statement and Requirement of Simple IP Multi-homing of the Host",
Min Hui, Hui Deng, 3-Nov-08, <draft-hui-ip-multiple-connections-ps-01.txt>
This document discusses current issues with simple IP multi-homing.
In order to have deep understanding of the issue, the document also
analyzes related works in IETF. In the end gives the requirements of
the simple IP multi-homing in concern of technical implements. Simple
IP multi-homing focuses on simultaneous multiple IP connections of
the host.
"MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov
Weingarten, 7-Jul-08, <draft-sprecher-opsawg-mplstp-oam-analysis-00.txt>
The intention of this document is to analyze the set of requirements
for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to
verify whether the existing MPLS OAM tools can be applied to these
requirements, identify which of the existing tools need to be
extended, and which new tools should be defined. Eventually, the
purpose of the document is to recommend which of the existing tools
should be extended and what new tools should be defined to support
the set of OAM requirements for MPLS-TP.
"The requirement and proposal of extenting M3UA signalling network route
management", Xu Chen, Hao Zhang, Xiaodong Duan, Zhao Yuyi, Li Xinyan,
7-Jul-08, <draft-chen-sigtran-m3ua-extension-00.txt>
RFC 4666 defines M3UA a protocol for supporting the transport of any
SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using
the services of the Stream Control Transmission Protocol. M3UA is
designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP
applications, so the network level management function isn't
required. But when M3UA is used in IP based signaling network, the
network level management function needs to be extended. This
document provides the proposals for extending M3UA signalling network
route management. This document is consistent with RFC4666 in other
sides.
"Suggested process changes for handling new SIP headers and SIP responses",
Keith Drage, 7-Jul-08, <draft-drage-rai-sip-header-process-00.txt>
RFC 3427 currently defines the process for defining and registering
new SIP header fields. This document proposes that prefixs to header
field names should be discontinued, and that an additional category
of experimental header field should be created. This document also
relaxes the requirement that response codes are defined by standards
track RFCs, also allowing them to be defined by experimental RFCs.
"Best Current Practice for IP-based In-Vehicle Emergency Calls", Brian Rosen,
Hannes Tschofenig, Ulrich Dietz, 15-Jul-08, <draft-rosen-ecrit-ecall-01.txt>
This document describes how to use a subset of the IETF-based
emergency call framework for accomplishing emergency calling support
in vehicles. Simplifications are possible due to the nature of the
functionality that is going to be provided in vehicles with the usage
of GPS. Additionally, further profiling needs to be done regarding
the encoding of location information.
"Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne,
7-Jul-08, <draft-tschofenig-ecrit-trustworthy-location-00.txt>
For location-based applications, such as emergency calling or
roadside assistance, the identity of the requestor is less important
than accurate and trustworthy location information.
A number of protocols are available to supply end systems with either
civic or geodetic information. For some applications it is an
important requirement that location information has not been modified
in transit or by the end point itself.
This document investigates different threats, the adversary model,
and outlines three possible solutions. The document concludes with a
suggestion on how to move forward.
"A Session Initiation Protocol (SIP) Event Package for Location Information",
James Winterbottom, Martin Thomson, Hannes Tschofenig, 7-Jul-08,
<draft-winterbottom-sip-location-package-00.txt>
This document specifies a SIP event package allowing allowing a
location receiptient to subscribe for location information when
provided a location URI using the sip, sips, or pres URI schemes.
The notification that results from the subscription is either the
location of the Target or an error.
"MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov
Weingarten, 3-Sep-08, <draft-sprecher-mpls-tp-oam-analysis-02.txt>
The intention of this document is to analyze the set of requirements
for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to
verify whether the existing MPLS OAM tools can be applied to these
requirements, identify which of the existing tools need to be
extended, and which new tools should be defined. Eventually, the
purpose of the document is to recommend which of the existing tools
should be extended and what new tools should be defined to support
the set of OAM requirements for MPLS-TP.
"Link properties advertisement from modem to router", Lloyd Wood, Rajiv
Asati, Daniel Floreani, 14-Jul-08,
<draft-wood-dna-link-properties-advertisement-01.txt>
Routers are increasingly connected to a variety of smart modems.
Such a modem's incoming and outgoing link rates can be varied over
time with adaptive coding and modulation to suit the channel
characteristics. The link rate and conditions offered by the modem
to connected devices therefore vary. For connected devices to
condition traffic and get the most out of the modem's link capacity,
they need to know the modem's link conditions. This document
describes one simple method for the modem to advertise link rate and
other characteristics, via UDP messages, and discusses alternative
approaches to communicating this information.
"Independent Session Control Feature for TWAMP", Al Morton, 7-Jul-08,
<draft-morton-ippm-twamp-session-cntrl-00.txt>
The IETF is completing its work on TWAMP - the Two-Way Active
Measurement Protocol. This memo describes a proposed feature for
TWAMP, intended for discussion in the IP Performance Metrics WG. The
feature gives the sender the ability to start and stop one or more
test sessions using the Session Identifiers.
"Why should the Traffic Optimization not be restricted to the
Application-Layer?", Damien Saucez, Dimitri Papadimitriou, 7-Jul-08,
<draft-saucez-alto-generalized-alto-00.txt>
The Application-Layer Traffic Optimization (ALTO) problem is being
discussed within the IETF and more globally by the research community
and some enterprises. In this memo, we argue that it is important to
conceive general-purpose mechanisms to solve this problem. By
general-purpose we say not only application independent but also
layer independent mechanism. The generality can be obtained because
the underlying problem is the same regardless the application or the
layer.
"Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA')", Jari Arkko, Vesa Lehtovirta,
Pasi Eronen, 18-Nov-08, <draft-arkko-eap-aka-kdf-10.txt>
This specification defines a new EAP method, EAP-AKA', a small
revision of the EAP-AKA method. The change is a new key derivation
function that binds the keys derived within the method to the name of
the access network. The new key derivation mechanism has been
defined in the 3rd Generation Partnership Project (3GPP). This
specification allows its use in EAP in an interoperable manner. In
addition, EAP-AKA' employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187 EAP-AKA to prevent bidding
down attacks from EAP-AKA'.
"A Uniform Resource Name (URN) Namespace for CableLabs", Eduardo Cardona,
Sumanth Channabasappa, Jean-Francois Mule, 6-Jul-08,
<draft-cardona-cablelabs-urn-00.txt>
This document describes the Namespace Identifier (NID) for Uniform
Resource Namespace (URN) resources published by Cable Television
Laboratories Inc. (CableLabs). CableLabs publishes specifications
that define unique and persistent resources that make use of the
cablelabs URN namespace.
"TCP Flow Control for Fast Startup Schemes", Michael Scharf, Sally Floyd,
Pasi Sarolahti, 7-Jul-08, <draft-scharf-tcpm-flow-control-quick-start-00.txt>
This document describes extensions for the flow control of the
Transmission Control Protocol (TCP) that avoid interactions with fast
startup congestion control mechanisms, in particular the Quick-Start
TCP extension. Quick-Start is an optional TCP extension that allows
to start data transfers with a large congestion window, using
feedback of the routers along the path. This can avoid the time
consuming Slow-Start, provided that the TCP flow control is not a
limiting factor.
There are two potential interactions between the TCP flow control and
congestion control schemes without the standard Slow-Start: First,
receivers might not allocate a sufficiently large buffer space after
connection setup, or they may advertise a receive window implicitly
assuming the Slow-Start behavior on the sender side. This document
therefore provides guidelines for buffer allocation in hosts
supporting the Quick-Start extension. Second, the TCP receive window
scaling mechanism can prevent fast startups immediately after the
initial three-way handshake connection setup. This document
describes a simple solution to overcome this problem.
"OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff
Doyle, Emre Ertekin, Michael Lundberg, 7-Jul-08,
<draft-pillay-esnault-moyer-ospfv3-pece-00.txt>
Many Service Providers (SPs) offer the 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.
"Monitoring Architectures for RTP", Geoff Hunt, Philip Arden, 7-Jul-08,
<draft-hunt-avt-monarch-00.txt>
This memo is intended to stimulate discussion on a hierarchical
monitoring architecture for RTP, including a scheme for the
definition of lower-layer metrics which are usable by a range of
applications. Systematic investigation of a monitoring architecture
for RTP/RTCP was requested at the IETF71 (Philadelphia) AVT session.
This first version of the draft is restricted to transport metrics
and to a subset of audio application metrics, but it is envisaged
that future work should extend this to other applications,
principally video.
"SRTP Store and Forward", Rolf Blom, Yi Cheng, Fredrik Lindholm, John
Mattsson, Mats Naslund, Karl Norrman, 3-Nov-08,
<draft-mattsson-srtp-store-and-forward-01.txt>
The Secure Real-time Transport Protocol (SRTP) was designed to allow
simple and efficient protection of RTP. To provide this, encryption
and authentication of media and control signaling are tightly coupled
to the RTP session, and to the information in the RTP header. Hence,
in general it is not possible to perform store and forward of
protected media.
This document gives, based on a use case analysis, requirements that
SRTP and new SRTP transforms need to satisfy in order to allow secure
store-and-forward operation. A first proposal on how to introduce
the needed new functionality and transforms in SRTP is also
presented.
"JWT Report on MPLS Architectural Considerations for a Transport Profile",
Stewart Bryant, Loa Andersson, 7-Jul-08,
<draft-bryant-mpls-tp-jwt-report-00.txt,.pdf>
This RFC archives the report of the IETF - ITU-T Joint Working Team
(JWT) on the application of MPLS to Transport Networks. The JWT
recommended of Option 1: The IETF and the ITU-T jointly agree to work
together and bring transport requirements into the IETF and extend
IETF MPLS forwarding, OAM, survivability, network management and
control plane protocols to meet those requirements through the IETF
Standards Process. There are two versions of this RFC. An ASCII
version that contains a summary of the slides and a PDF version that
contains the summary and a copy of the slides.
"Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6
Domains", Niklas Neumann, Xiaoming Fu, Jun Lei, Gong Zhang, 7-Jul-08,
<draft-neumann-netlmm-inter-domain-00.txt>
This document specifies mechanisms to setup and maintain handover and
data forwarding procedures that allow a mobile node to move between
different domains that provide (localized) network-based mobility
support based on Proxy Mobile IPv6 for that node.
"A Session Initiation Protocol (SIP) Load Control Event Package", Charles
Shen, Henning Schulzrinne, Arata Koike, 3-Nov-08,
<draft-shen-sipping-load-control-event-package-01.txt>
This document defines a load control event package for the Session
Initiation Protocol (SIP). It allows SIP servers to distribute user
load control information to SIP servers. The load control
information can throttle outbound calls based on their destination
domain, telephone number prefix or for a specific user. The
mechanism helps to prevent signaling overload and complements
feedback-based SIP overload control efforts.
"The Global HAHA Operation at the Interop Tokyo 2008", Ryuji Wakikawa,
Keiichi Shima, Noriyuki Shigechika, 7-Jul-08,
<draft-wakikawa-mext-haha-interop2008-00.txt>
This document describes the protocol design consideration of the
correspondent router for the NEMO Basic Support Protocol.
"The Design Consideration of Correspondent Router", Ryuji Wakikawa, 7-Jul-08,
<draft-wakikawa-mext-cr-consideration-00.txt>
This document describes the protocol design consideration of the
correspondent router for the NEMO Basic Support Protocol.
"NEMO Basic Support for Fixed Access Networks", Ryuji Wakikawa, Shin
Miyakawa, 7-Jul-08, <draft-wakikawa-nemo-fixed-access-network-00.txt>
This document describes the usage of Network Mobility (NEMO) for the
commercial ISPs. NEMO can be a mechanism to provide IP subscription.
"Marking Converter for Excess-Marked Traffic", Michael Menth, Frank
Lehrieder, 7-Jul-08, <draft-menth-pcn-marking-converter-00.txt>
This document proposes an algorithm that converts packet markings of
a stream that was excess-marked based on a lower-rate into packet
markings that correspond to a stream that was excess-marked based on
a higher-rate. It may be applied in the PCN context to convert
marked admissible-rate-overload into marked supportable-rate-
overload. This allows to perform marked flow termination when
packets are excess-marked based on the admissible rate only.
"End-to-End Identity Important in the Session Initiation Protocol (SIP)",
John Elwell, 25-Oct-08, <draft-elwell-sip-e2e-identity-important-01.txt>
This document surveys existing mechanisms in the Session Initiation
Protocol (SIP) for identifying and authenticating the source of a SIP
request (or caller identification). It describes how identification
and authentication are not always end-to-end and the problems that
this can lead to, particularly since media security based on
techniques such as DTLS-SRTP is dependent on end-to-end authenticated
identification of parties.
This work is being discussed on the sip@ietf.org mailing list.
"RUCUS Test Cases", David Schwartz, 7-Jul-08,
<draft-schwartz-rucus-test-cases-00.txt>
This document is meant to serve as a repository for test cases
assoicated with taking some action upon receipt of unwanted
communications.
"A way for a host to indicate support for 240.0.0.0/4 addresses", Teemu
Savolainen, 7-Jul-08, <draft-savolainen-indicating-240-addresses-00.txt>
This document describes how the 240.0.0.0/4 address space can be
taken into use in incremental and backwards compatible manner in
certain networks, and how reclassification of 240.0.0.0/4 address
space as private would help Internet growth and transition to IPv6.
"IPv4 support in PMIP-MIP interaction", Desire Oulai, Suresh Krishnan,
7-Jul-08, <draft-oulai-netlmm-mip-interaction-v4support-00.txt>
PMIPv6 and MIPv6 are respectively the leading protocols for network
based and client based mobility. As backward compatibility is an
important feature, IPv4 support for PMIPv6 and MIPv6 becomes
mandatory. This document highlights some scenarios for PMIPv6-MIPv6
interaction with IPv4 support as well as some proposed solutions.
"Key Data for a Registry Provisioning Interface
draft-guyton-drinks-registry-data-00.txt", Debbie Guyton, 7-Jul-08,
<draft-guyton-drinks-registry-data-00.txt>
This document defines data that should be included in a provisioning
interface for a Registry. The provisioning interface may be used in
(near) real time, or periodically, from a service provider's service
provisioning system to establish and administer telephone number (TN)
and associated routing information in the Registry after necessary
validations. Based on 1) effective date/time specified for the data
and 2) validation of the TN assignee, these data will be used to
define selective routing views for various recipient service providers
which would be reflected in ENUM-SIP address servers. In addition,
the concept of multiple TNs sharing a common routing pattern simplifies
the definition and administration of routing data.
D. Guyton
Expires 01/07/09
[page 1]
Registry Provisioning Interface
July 2008
"Local Forwarding in Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury,
7-Jul-08, <draft-koodli-netlmm-local-forwarding-00.txt>
With bidirectional tunneling in Proxy Mobile IPv6, the communication
between any two Mobile Nodes is required to traverse the Local
Mobility Anchor (LMA). This is the case even when the communicating
Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG).
This document introduces two messages between the LMA and the MAG
enabling local forwarding by the MAG. Such forwarding avoids the
delay due to bidirectional forwarding, and reduces the traffic load
on the LMA.
"Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Basavaraj
Patil, Suresh Krishnan, 14-Jul-08,
<draft-premec-netlmm-bulk-re-registration-01.txt>
The 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 mechanism is also
intended to be used by a MAG to re-establish bindings at a new LMA
when its old LMA fails.
"Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows
in FEC Framework", Ulas Kozat, Ali Begen, 7-Jul-08,
<draft-kozat-fecframe-pseudo-cdp-00.txt>
This document provides a pseudo Content Delivery Protocol (CDP) to
protect multiple source flows with one or more repair flows based on
the FEC Framework document and the Session Description Protocol (SDP)
elements defined for the framework. The purpose of the document is
not to provide a full-pledged protocol, but to show how the defined
framework and SDP elements can be combined together to design a CDP.
"Problem Statement: Link Degradation Isolation in Interoperable Networks
using Intermediate System to Intermediate System (IS-IS)", Zhenqiang Li,
Lianyuan Li, Xiaodong Duan, 7-Jul-08,
<draft-li-isis-degradation-isolation-problem-00.txt>
IS-IS protocol specifies a procedure that if a Link State Protocol
Data Unit (LSP) with an incorrect LSP Checksum is received, the
corruptedLSPReceived circuit event will be generated and the
corrupted LSP will be discarded. This document aims to emphasize that
although this procedure can maintain the network stability, it can
not diagnose and isolate the source of the network problem. In some
cases this procedure will create bad effect on the services carried
by the network. This document suggests that IS-IS protocol introduce
the mechanism for link degradation detection and isolation, which
should be triggered when corrupted LSP is received.
"Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Carlos
Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08,
<draft-bernardos-mext-miron-00.txt>
The Network Mobility Basic Support protocol enables networks to roam
and attach to different access networks without disrupting the
ongoing sessions that nodes of the network may have. By extending
the Mobile IPv6 support to Mobile Routers, nodes of the network are
not required to support any kind of mobility, since packets must go
through the Mobile Router-Home Agent (MRHA) bi-directional tunnel.
Communications from/to a mobile network have to traverse the Home
Agent, and therefore better paths may be available. Additionally,
this solution adds packet overhead, due to the encapsulation.
This document describes an approach to the Route Optimisation for
NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON
enables mobility-agnostic nodes within the mobile network to directly
communicate (i.e. without traversing the MRHA bi-directional tunnel)
with Correspondent Nodes. The solution is based on the Mobile Router
performing the Mobile IPv6 Route Optimisation signalling on behalf of
the nodes of the mobile network.
This document (in an appendix) also analyses how MIRON fits each of
the currently identified NEMO Route Optimisation requirements for
Operational Use in Aeronautics and Space Exploration.
"Teredo Extensions", Dave Thaler, 3-Nov-08,
<draft-thaler-v6ops-teredo-extensions-02.txt>
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.
"Correspondent Router based Route Optimisation for NEMO (CRON)", Carlos
Bernardos, Maria Calderon, Ignacio Soto, 7-Jul-08,
<draft-bernardos-mext-nemo-ro-cr-00.txt>
The Network Mobility Basic Support protocol enables networks to roam
and attach to different access networks without disrupting the
ongoing sessions that nodes of the network may have. By extending
the Mobile IPv6 support to Mobile Routers, nodes of the network are
not required to support any kind of mobility, since packets must go
through the Mobile Router-Home Agent (MRHA) bi-directional tunnel.
Communications from/to a mobile network have to traverse the Home
Agent, and therefore better paths may be available. Additionally,
this solution adds packet overhead, due to the encapsulation.
This document describes an approach to the Route Optimisation for
NEMO, based on the well-known concept of Correspondent Router. The
solution aims at meeting the currently identified NEMO Route
Optimisation requirements for Operational Use in Aeronautics and
Space Exploration. Based on the ideas that have been proposed in the
past, as well as some other extensions, this document describes a
Correspondent Router based solution, trying to identify the most
important open issues.
The main goal of this first version of the document is to describe an
initial NEMO RO solution based on the deployment of Correspondent
Routers and trigger the discussion within the MEXT WG about this kind
of solution.
This document (in an appendix) also analyses how a Correspondent
Router based solution fits each of the currently identified NEMO
Route Optimisation requirements for Operational Use in Aeronautics
and Space Exploration.
"BGP Class of Service Interconnection", Thomas Martin Knoll, 7-Jul-08,
<draft-knoll-idr-cos-interconnect-00.txt>
This document focuses on Class of Service Interconnection at inter-
domain peering points. It specifies two new non-transitive
attributes, which enable adjacent peers to signal Class of Service
Capabilities and certain Class of Service admission control
Parameters. The new "CoS Capability Attribute" is deliberately kept
simple and denotes the general EF, AF Group and BE forwarding support
across the advertising AS. The second "CoS Parameter Attribute" is
of variable length and contains a more detailed description of
available forwarding behaviours using the PHB id Code encoding. Each
PHB id Code is associated with rate and size based traffic
parameters, which will be applied in the ingress AS Border Router for
admission control purposes to a given forwarding behaviour. The
denoted Class of Service forwarding support is meant as the AS
externally available (transit) Class of Service support.
"GDOI Generic Message Authentication Code Policy", Brian Weis, Sheela Rowles,
7-Jul-08, <draft-weis-gdoi-mac-tek-00.txt>
A number of IETF signaling and routing applications require a set of
devices to share the same policy and keying material and include a
message authentication code in their protocols packets for
authentication . It is often beneficial for this keying material to
be chosen dynamically using a group key management protocol. This
memo describes the policy required for the Group Domain of
Interpretation (GDOI) group key management system to distribute a
message authentication code key and associated policy.
"Datagram Transport Layer Security for Stream Control Transmission Protocol",
Michael Tuexen, Robin Seggelmann, Eric Rescorla, 7-Jul-08,
<draft-tuexen-tsvwg-dtls-for-sctp-00.txt>
This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol over the Stream Control Transmission
Protocol (SCTP).
The user of DTLS over SCTP can take advantage of all features
provided by SCTP and its extensions, especially support of
o multiple streams to avoid head of line blocking.
o multi-homing to provide network level fault tolerance.
o unordered delivery.
o partial reliable data transfer.
"The Use of Entropy Labels in MPLS Forwarding", Kireeti Kompella, Shane
Amante, 7-Jul-08, <draft-kompella-mpls-entropy-label-00.txt>
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.
"Raptor FEC Schemes for FECFRAME", Mark Watson, 7-Jul-08,
<draft-watson-fecframe-raptor-00.txt>
This document describes Fully-Specified Forward Error Correction
(FEC) Schemes for the Raptor code and its application to reliable
delivery of media streams in the context of FEC Framework. The
Raptor code is a systematic code, where a number of repair symbols
are generated from a set of source symbols and sent in one or more
repair flows in addition to the source symbols that are sent to the
receiver(s) within a source flow. The Raptor code offers a close to
optimal protection against arbitrary packet losses at a low
computational complexity. Two FEC Schemes are defined, one for
protection of arbitrary packet flows and another for protection of a
single flow that already contains a sequence number. Repair data may
be sent over arbitrary datagram transport (e.g. UDP) or using RTP.
An RTP Payload Type is defined for this latter case.
"Unicast-Based Rapid Synchronization with RTP Multicast Sessions", Bill
Steeg, Ali Begen, Tom Caenegem, 3-Nov-08,
<draft-versteeg-avt-rapid-synchronization-for-rtp-01.txt>
When a receiver joins a multicast session, it may need to acquire and
parse certain key information before it can process any data sent in
the multicast session. Depending on the join time, length of the key
information repetition interval, size of the key information as well
as the application and transport properties, the time lag before a
receiver can usefully consume the multicast data, which we refer to
as the synchronization delay, varies and may 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 existing RTP and RTCP protocol
machinery that reduces the synchronization delay. In this method, an
auxiliary unicast RTP session carrying the key information to the
receiver precedes/accompanies the multicast flow. This unicast flow
may be transmitted at a faster than natural rate to further
accelerate the synchronization. The motivating use case for this
capability is multicast applications that carry real-time compressed
audio and video. However, the proposed method can also be used in
other types of multicast applications where the synchronization delay
is long enough to be a problem.
"TICTOC Requirement", Silvana Rodrigues, Kurt Lindqvist, 17-Nov-08,
<draft-rodrigues-lindqvist-tictoc-req-01.txt>
Distribution of high precision time and frequency over the Internet
and special purpose IP networks is becoming more and more needed as
IP networks replace legacy networks and as new applications with need
for frequency and time are developed on the Internet. The IETF
formed the TICTOC workinggroup to address the problem and perform an
analysis on existing solutions and the needs. This document
summarises application needs, as described and agreed on at an TICTOC
interim meeting held in Paris from June 16 to 18, 2008.
"Generic Ethernet Pseudowire", Shane Amante, Giles Heron, Andrew Malis, Vach
Kompella, Florin Balus, 15-Jul-08,
<draft-vkompella-pwe3-ethernet-pw-bis-01.txt>
This draft proposes a simpler approach to handling various
encapsulations of Ethernet packets over a pseudowire, over the
existing Ethernet Pseudowire definition in [RFC4448].
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri
Papadimitriou, JP Vasseur, 7-Jul-08,
<draft-berger-mpls-gmpls-lsp-reroute-00.txt>
This document describes how Resource ReserVation Protocol (RSVP)
PathErr Messages may be used to trigger rerouting of Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering (TE) Label Switched Paths (LSPs) without first removing
LSP state or resources. Such LSP rerouting may desirable in a number
of cases including, for example, soft-preemption and graceful
shutdown. This document describes the usage of existing Standards
Track mechanisms and defines no new formats or mechanisms. It relies
on mechanisms already defined as part of RSVP-TE and simply describes
a sequence of actions to be executed.
"NETCONF Notification Content", Sharon Chisholm, Alex Clemm, Malcolm Betts,
7-Jul-08, <draft-chisholm-netconf-not-content-00.txt>
The NETCONF Event Notifications standard specifies the mechanism by
which NETCONF clients can subscribe to and receive event
notifications. However, with the exception of a timestamp, no
standard Notification content was defined. This memo defines a set
of information that should be included in all NETCONF notifications,
information that should be included based on class of notification
and also defines a set of specific notifications to support specific
management functions, such as configuration.
"Requirements for OAM in MPLS Transport Networks", Martin Vigoureux, David
Ward, Malcolm Betts, Matthew Bocci, Italo Busi, 1-Nov-08,
<draft-vigoureux-mpls-tp-oam-requirements-01.txt>
This document lists the requirements for Operations, Administration
and Maintenance functionality in MPLS networks that are used for
packet transport services and network operations.
These requirements are derived from the set of requirements specified
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5].
"PCN Encoding for Packet-Specific Dual Marking (PSDM)", Michael Menth, Jozef
Babiarz, T Moncaster, Bob Briscoe, 7-Jul-08,
<draft-menth-pcn-psdm-encoding-00.txt>
This document proposes how PCN marks can be encoded into the IP
header. The presented encoding reuses the ECN field of the Voice-
Admit DSCP in a single PCN domain. The encoding of unmarked PCN
packets indicates whether they are subject to either excess- or
exhaustive-marking. This is useful, e.g., when data and probe
packets require different marking mechanisms.
Status
This memo is posted as an Internet-Draft with an intent to eventually
be published as an experimental RFC.
"A Framework for MPLS in Transport Networks", Matthew Bocci, Stewart Bryant,
31-Oct-08, <draft-blb-mpls-tp-framework-01.txt>
This document specifies an archiectectural framework for the
application of MPLS in transport networks. It describes a profile of
MPLS that enables operational models typical in transport networks
networks, while providing additional OAM, survivability and other
maintenance functions not currently supported by MPLS.
"Private Extensions to the Session Initiation Protocol (SIP) for Asserter
Identification within Trusted Networks", Hadriel Kaplan, 7-Jul-08,
<draft-kaplan-sip-asserter-identity-00.txt>
This document describes private extensions to the Session
Initiation Protocol (SIP) that enable a network of trusted SIP
servers to identify the asserter of private user identity defined
in RFC 3325. The use of these extensions is only applicable
inside a set of administrative domains with previously agreed-upon
policies for generation, transport and usage of such information.
This document does NOT offer a general identity model suitable for
use between different trust domains, or use in the Internet at
large.
"Simplified VPLS-PBB interworking via MMRP", David Allan, Nigel Bragg, Dinesh
Mohan, 7-Jul-08, <draft-allan-mmrp-for-mac-in-mac-00.txt>
This document describes how MAC filtering programmed by the IEEE
multiple MAC registration protocol (MMRP or 802.1ak) can be employed
by VPLS-PE devices as the exclusive mechanism for interworking with
802.1ah PBBNs. No new protocol standardization is required to do
this, however there are small procedural changes associated with the
interworking of protocols.
"DHCPv4 Vendor-specific Message", Bernie Volz, 7-Jul-08,
<draft-volz-dhc-dhcpv4-vendor-message-00.txt>
This document requests a vendor-specific DHCPv4 message assignment.
This message can be used for vendor specific and experimental
purposes.
"Uses of policy control in routing", Anne-Louise Burness, 7-Jul-08,
<draft-irtf-burness-policy-00.txt>
When considering a new routing system, we need to ensure that it is
able to meet the functionality requirements of the participant
networks. One aspect that is frequently over-looked is that routing
is rarely a simple matter of choosing a least-hop path. This
document attempts to highlight some of the more common policy choices
that are made. We expect that policies that are in common use today
should be easy to implement with any new routing schemes. Any
routing scheme make it possible or significantly easier to implement
the harder policies would have an implementation advantage.
"Enhanced BGP Capabilities for Exchanging Second-Best Paths", Brian Dickson,
13-Jul-08, <draft-dickson-add-paths-ordered-01.txt>
This Internet Draft describes an enhanced format for encoding prefix
information, to permit multiple copies of a prefix with different
paths to be announced and withdrawn.
Prefix instances using the new format include both unique
identifiers, and ordinals to control path selection.
Withdrawal of prefixes requires a slight modification to disambiguate
prefix instances.Author's Note
This Internet Draft is intended to result in this draft or a related
draft(s) being placed on the Standards Track for idr.
"Enhanced BGP Capabilities for Exchanging Additional Nth-Best Paths", Brian
Dickson, 13-Jul-08, <draft-dickson-idr-well-ordered-nth-best-01.txt>
This Internet Draft describes an enhanced way to exchange prefix
information, so as to permit multiple copies of a prefix, with
different paths, to be announced and withdrawn.
This negotiated capability facilitates faster local (inter-AS) and
global (intra-AS) convergence, reduces path-hunting, improves route-
reflector behaviour, including eliminating persistent oscillations.
Additional prefix instances have a new wire format for updates and
withdrawals, to control path selection.
Benefits are seen both when deployed intra-AS, and on inter-AS
peering.
Author's Note
This Internet Draft is intended to result in this draft or a related
draft(s) being placed on the Standards Track for idr.
"End-to-end Extension for PCN Encoding", Michael Menth, Jozef Babiarz, T
Moncaster, 7-Jul-08, <draft-menth-pcn-e2e-encoding-00.txt>
This document proposes an encoding of PCN marks based on the ECN
field of the Voice-Admit DSCP. It has global meaning and ECN
semantics are not applied to that field. The PCN codepoints are the
same as those for packet-specific dual marking (PSDM) within a single
PCN domain, but the general concept can also be applied to other
encodings requiring only a single PCN-enabled DSCP.
"Opaque MSRP Path Uri", Derek MacDonald, Hadriel Kaplan, 7-Jul-08,
<draft-macdonald-simple-msrp-opaque-path-00.txt>
The Message Session Relay Protocol(MSRP) does not allow efficient
topology hiding, such that MSRP users can hide the IP Address of
their systems. This limitation is due to the fact that MSRP Path
headers contain physical IP addresses. This document describes a
mechanism which adds a level of indirection to allow topology hiding.
It defines the option tag msrp-opaque.
"Datagram Transport Layer Security Transport Model for SNMP", Wesley
Hardaker, 3-Nov-08, <draft-hardaker-isms-dtls-tm-01.txt>
This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides authentication
and privacy services for SNMP applications. This document describes
how the DTLS Transport Model (DTLSTM) implements the needed features
of a SNMP Transport Subsystem to make this protection possible in an
interoperable way.
This transport model is designed to meet the security and operational
needs of network administrators, operate in environments where a
connectionless (UDP) transport is preferred, and integrates well into
existing public keying infrastructures.
This document also defines a portion of the Management Information
Base (MIB) for monitoring and managing the DTLS Transport Model for
SNMP.
"Context-based Header Compression for 6lowpan", Carsten Bormann, 7-Jul-08,
<draft-bormann-6lowpan-cbhc-00.txt>
6lowpan (RFC 4944) so far has only defined stateless forms of header
compression. This document specifies how a node and a router can
agree on state that will allow much better header compression of
global addresses.
$Id: draft-bormann-6lowpan-cbhc.xml,v 1.2 2008/07/07 22:19:28 cabo
Exp $
"EDNS Option Code for Private Opaque Text", Hadriel Kaplan, Robert Walter,
Raja Gopal, Tom Creighton, 7-Jul-08,
<draft-kaplan-dns-opaque-text-opt-code-00.txt>
This document requests an IANA allocation for an EDNS Option code,
per [RFC2671], for an opaque text field for private use.
"IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 14-Jul-08,
<draft-boschi-ipfix-anon-01.txt>
This document describes anonymisation techniques for IP flow data.
It provides a categorization of common anonymisation schemes and
defines the parameters needed to describe them. It describes support
for anonymization within the IPFIX protocol, providing the basis for
the definition of information models for configuring anonymisation
techniques within an IPFIX Metering or Exporting Process, and for
reporting the technique in use to an IPFIX Collecting Process.
"An Extension to the Presence Information Data Format - Location Object
(PIDF-LO) for the Timezone of a Presentity", James Polk, Jonathan Rosenberg,
7-Jul-08, <draft-polk-geopriv-pidf-lo-timezone-element-00.txt>
The Presence Information Data Format - Location Object (PIDF-LO)
lacks an indication for the timezone offset of a particular
presentity is in. This document extends the PIDF-LO for including
such an XML element.
"Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples",
Mary Barnes, Chris Boulton, Lorenzo Miniero, Simon Romano, 7-Jul-08,
<draft-barnes-xcon-examples-00.txt>
This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. The call flows document the use of the interface
between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). The
objective is to provide a base reference for both protocol
researchers and developers.
"Nominating Committee Process: Issues since RFC 3777", Spencer Dawkins, Danny
McPherson, 7-Jul-08, <draft-dawkins-nomcom-3777-issues-00.txt>
This document describes issues with the current IETF Nominating
Committee process that have arisen in practice.
"AS4-specific RD/RT/SOO Capability exchange", Samita Chakrabarti, 7-Jul-08,
<draft-chakrabarti-idr-as4-route-cap-01.txt>
RFC 4893 defines BGP support for four-octet AS number space for
handling AS_PATH attributes and "My ASN" value in BGP OPEN messages.
Foue-Octet AS specific Extended Community attribute formats are
defined in draft-rekhter-as4octet-ext-community-03.txt. However, an
implementation compliant to RFC 4893 does not necessarily provide
support for 4-Octet Route-distinguisher, Route-target or Site-of-
origin in the BGP-MPLS-VPN. Thus BGP capability exchange for
extended AS number attribute does not cover the BGP-MPLS-VPN AS4-
specific route-attributes and route-distinguishers. This document
proposes an optional BGP capability exchange between the Provider
Edge (PE) routers in order to communicate the intention of handling
4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of-
Origins or being able to handle and inteprete the 4-Octet route-
distinguishers correctly. This capability parameter will be part of
OPEN message during the BGP session initiation.
"The Importance of a Visual Identifier of Trusted Identity", Dan York,
3-Nov-08, <draft-york-sip-visual-identifier-trusted-identity-01.txt>
This document discusses the need for a visual identifier in Session
Initiation Protocol (SIP) endpoints to indicate to the end user that
they are speaking with someone whose identity is trusted.
"Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc
Petit-Huguenin, 3-Nov-08, <draft-petithuguenin-behave-stun-pmtud-02.txt>
This document describes a Session Traversal Utilities for NAT (STUN)
usages for discovering the path MTU between a client and a server.
"PBS NSLP: Network Traffic Authorization", Se Gi Hong, Henning Schulzrinne,
3-Nov-08, <draft-hong-nsis-pbs-nslp-02.txt>
This document describes the NSIS Signaling Layer protocol (NSLP) for
network traffic authorization on the Internet, the Permission-Based
Sending (PBS) NSLP. This NSLP aims to prevent Denial-of-Service
(DoS) attacks and other forms of unauthorized traffic. PBS NSLP is
based on the proactive approach of explicitly granting permissions
and the reactive approach of monitoring and reacting against the
attacks. Signaling installs and maintains the permission state of
routers for a data flow. PBS NSLP uses two security mechanisms:
message security in an end-to-end fashion and channel security in a
hop-by-hop fashion. The message security is for protecting the
integrity of the message on end-to-end traffic and channel security
is for protecting the integrity and confidentiality between adjacent
nodes. These security mechanisms enable the secure distribution of
shared keys, as well as protection of signaling messages. To
authenticate data packets, the PBS NSLP requests a sender to use an
existing security protocol, the IPsec Authentication Header (AH).
This allows routers to drop bogus packets by using an IP packet
filter. To avoid a compromised router that drops legitimate packets,
the PBS NSLP triggers the sender to change the data flow path.
"Signaled PID When Multiplexing Multiple Payloads over RSVP-TE LSPs", Zafar
Ali, 7-Jul-08, <draft-ali-mpls-sig-pid-multiplexing-case-00.txt>
There are many deployment scenarios where an RSVP-TE LSP carries
multiple payloads. In these cases, it gets ambiguous on what
should value should be carried as L3PID in the Label Request
Object [RFC3209] or G-PID in the Generalized Label Request Object
Expires January 2009
[page 1]
draft-ali-mpls-sig-pid-multiplexing-case-00.txt
[RFC3471], [RFC3473]. The document propose use of some dedicated
PID values to cover some typical cases of multiple payload
carried by the LSP, including that indicates to the egress node
to ignore signaling to learn payload carried by the LSP.
"IPv4 ID Uniqueness Requirements", Joseph Touch, Matt Mathis, 7-Jul-08,
<draft-touch-intarea-ipv4-unique-id-00.txt>
The IPv4 Identification field enables fragmentation and reassembly.
This document clarifies the meaning of this field in the absence of
fragmentation, based on ubiquitous current practice.
"Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley,
7-Jul-08, <draft-touch-intarea-tunnels-00.txt>
This document discusses the role of tunnels in the Internet
architecture. It explains their relationship to existing protocol
layers, and the challenges in supporting tunneling.
"The Location "On Behalf Of" Model is Broken", Marc Linsner, 7-Jul-08,
<draft-linsner-geopriv-obo-00.txt>
There is proposed solution submitted to the GeoPriv work group that
outlines the need for a location recipient to obtain the location of a
target without the target's knowledge. The scenario is described as
supporting a legacy device (a device lacking support for location) for
the purposes of utilizing location when the legacy device summons
emergency help (by dialing 911/112, etc.). Below is a discussion of
the of the general topic of discovering location via 'On Behalf Of' or
OBO.
"Requirements of One-way Passive Measurement for End-to-End Quality", Yutaka
Kikuchi, Satoru Matsushima, Kenichi Nagami, Satoshi Uda, 7-Jul-08,
<draft-kikuchi-passive-measure-reqs-00.txt>
This draft describes the necessary requirements to passively measure
end-to-end quality and to monitor them via applicable ways. This
feature is crucial for Service Providers (SPs), especially who
provide transports with Service Level Agreements (SLAs).
"On the Relative Importance of P2P Peer Selection", Patrick Crowley,
7-Jul-08, <draft-crowley-alto-importance-01.txt>
This Internet-draft discusses the relative importance of path
selection in peer-to-peer (P2P) applications in light of the recent
discussions highlighting the conflict between the use of P2P
applications and the costs borne by network infrastructure operators.
"Definition of Managed Objects for the Manet Simplified Multicast Framework
Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy,
3-Nov-08, <draft-cole-manet-smf-mib-01.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the
Simplified Multicast Forwarding (SMF) process. The SMF MIB also
reports state information, performance metrics, and notifications.
In addition to configuration, this additional state and performance
information is useful to management stations troubleshooting
multicast forwarding problems.
"Transport for Advanced Networking Applications (TANA) Problem Statement",
Stanislav Shalunov, 14-Jul-08, <draft-shalunov-tana-problem-statement-01.txt>
The IETF P2PI workshop conducted in the end of May 2008 at MIT in
Boston has identified a number of potential documents for the IETF to
work on.
One is a transport protocol with congestion control mechanism that
enables an advanced networking application to minimize the extra
delay it induces in the bottleneck while implementing an end-to-end
version of scavenger service. At least one such protocol has now
been implemented by a major peer-to-peer application and deployed in
the wild with favorable results.
Another is a document that addresses community concerns about the use
of multiple transport connections by peer-to-peer applications, both
when these connections run to the same peer and to different peers.
These two items appear to fall within the Transport area, but not
within the charter of any existing working group. It is not obvious
what WG's charter could be naturally extended to encompass these two
items. The TANA BoF is held to explore the problem space, gauge the
interest in the problems within the Transport area, and to see if the
community and the area directors believe that it makes sense to form
a TANA working group within the Transport area chartered to work on
1. standardizing end-to-end congestion control that enables advanced
application to minimize the delay they introduce into the network
and a protocol using it and
2. a document describing the current practice of peer-to-peer apps'
use of multiple transport connections and recommendations in this
space.1. Requirements notation
"HIP Extensions for Object to Object Communications", Gyu Myoung Lee, Jun
Kyun Choi, Taesoo Chung, 3-Nov-08, <draft-lee-hip-object-01.txt>
This document explains the concept of object to object communications
and specifies naming and addressing issues for object identification.
In order to use Host Identity Protocol (HIP) for object to object
communications, this document provides the extended architecture of
HIP according to mapping relationships between host and object(s). In
addition, packet formats and considerations for HIP extensions
concerning object are specified.
"Customer MAC Address Flushing Mechanisms for Provider Backbone Bridging over
VPLS", Ali Sajassi, Samer Salam, Luyuan Fang, Nabil Bitar, Dinesh Mohan,
7-Jul-08, <draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt>
The scalability of H-VPLS (either with MPLS or Ethernet access
network) can be improved by incorporating Provider Backbone Bridge
(PBB) functionality in VPLS access.
PBB introduces the notion of Backbone MAC (B-MAC) addresses vs.
Customer MAC (C-MAC) addresses, thereby leading to the requirement
for having MAC address flushing mechanisms for each.
This document discusses a C-MAC address flushing notification
mechanism to be used in VPLS networks that employ PBB technology.
"Provider Backbone Bridges in H-VPLS with MPLS Access", Ali Sajassi, Samer
Salam, Nabil Bitar, Dinesh Mohan, 7-Jul-08,
<draft-sajassi-l2vpn-pbb-vpls-mpls-access-00.txt>
Provider Backbone Bridge (PBB) functionality, under standardization
in IEEE 802.1ah, can be employed to enhance the scalability of H-
VPLS with MPLS access. This document describes how PBB technology
can be used in H-VPLS with MPLS access networks to improve the
scalability of customer MAC addresses and number of service
instances that can be supported. The document also describes the
migration mechanisms and scenarios by which PBB functionality can be
incorporated into H-VPLS with existing MPLS access.
"Applicability of Access Node Control Mechanism to PON based Broadband
Networks", Nabil Bitar, Sanjay Wadhwa, 7-Jul-08,
<draft-bitar-wadhwa-ancp-pon-00.txt>
The purpose of this document is to provide applicability of Access
Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband
access. The need for an Access Node Control Mechanism between a Network Access
Server (NAS) and an Access Node Complex (a combination of Optical Line Termination
(OLT) and Optical Network Termination (ONT) elements), is described in a
multi-service reference architecture in order to perform QoS-related, service-
related and Subscriber-related operations. The Access Node Control
Mechanism is also extended for interaction between components of the
Access Node Complex (OLT and ONT). The Access Node Control mechanism
will ensure that the transmission of the information does not need to
go through distinct element managers but rather uses a direct device-
device communication. This allows for performing access link related
operations within those network elements to meet performance objectives.
"6LoWPAN Architectural Consideration for Mobility", Geoffrey Mulligan, Carl
Williams, David Huo, 3-Nov-08, <draft-williams-6lowpan-mob-01.txt>
The 6LoWPAN problem statement [RFC4919] provides for a goal that
6LowPAN devices have simple interconnectivity to other IP networks
including the Internet. Such interconnectivity means that a global
reachability requirement to 6lowpan networks is part of the 6LoWPAN
architecture. Here the 6LoWPAN devices must be reachable by any
corresponding node, independent of the current location. The 6LoWPAN
architecture also describes support for various topologies which
require mobility support.
Architectural considerations and analysis for mobility is needed to
ensure proper performance for these usage scenarios. The
architectural considerations for mobility may present unique
challenges to the 6LoWPAN given their requirements for low memory and
power constraints. Hence it is best to have mobility as an
architectural 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.
"AntiVirus Markup Language(AVML)", Antiy Labs, Antiy Labs, 11-Jul-08,
<draft-malware-avml-01.txt>
This document describes the AntiVirus Markup Language(AVML). AVML is
common standards language for storage, interaction and statistics of
malicious software information. Malware information described by
AVML More easily is dealt in distributed system. At the same time,
people can read it . This document defines the AVML and explains the
elements in AVML.
"General Virus Process Language(GVPL)", Antiy Labs, Antiy Labs, 9-Jul-08,
<draft-malware-gvpl-00.txt>
General Virus Process Language (GVPL) is lua scripting language
expansion. It is designed to dispose of the virus which found in
network terminal quickly. Because of the flexibility and simplicity
of Lua script, GVPL is easy to achieve the goal which is rapid
response to large-scale expansion of the virus. At the same time,it
will reduce economic losses of users.
"Mapping and interworking of Diversion information Between Diversion and
History-Info Headers in the Session Initiation Protocol (SIP)", Marianne
Mohali, 1-Nov-08, <draft-mohali-diversion-history-info-01.txt>
Diversion header is not standardized but widely used to convey
diverting information in Session Initiation Protocol (SIP) signaling.
This informational document proposes a way to make interwork call
diversion information contained in a Diversion header with a History-
Info header or with the Voicemail-URI which are standardized
solutions. In addition, an interworking policy is proposed to manage
the headers coexistence.
The History-Info header is described in [RFC4244] and the Voicemail
URI in [RFC4458].
Since the Diversion header is used in many existing networks
implementations for transport of diversion informationand its
interworking with standardized solutions is not obvious, an
interworking recommendation is needed.
"DNS Encryption", Duane Groth, 14-Jul-08,
<draft-groth-dns-encryption-02.txt,.pdf>
This document requests IANA registration of a new DNS OpCode and
ErrorCode type in facilitating encryption of DNS requests and
replies and feed back to the client if plain text requests are not
acceptable. Once this OpCode is seen the DNS server attempts to
decrypt the request using its private OpenPGP key. Inside the
encrypted packet is the AES key which the client expects to be used
when the server encrypts a response. A server may advertise that it
is capable of DNS encryption by returning OpenPGP fingerprints in
TXT records using a similar format to Public Key Association (PKA).
The full pubic keys are returned from DNS servers by using a CERT
request against the host name(s) of the domain's NS records or via
OpenPGP key servers.
"RTP Payload Format for the iSAC Codec", Tina le Grand, Paul Jones,
12-Jul-08, <draft-legrand-rtp-isac-00.txt>
iSAC is a proprietary wideband speech and audio codec developed by
Global IP Solutions, suitable for use in Voice over IP applications.
This document describes the payload format for iSAC generated bit
streams within an RTP packet. Also included here are the necessary
details for the use of iSAC with the Session Description Protocol
(SDP).
"Commercial Routing Requirements in Low Power and Lossy Networks", Jerry
Martocci, Ted Humpal, Nicolas Riou, Jon Williamsson, 14-Jul-08,
<draft-martocci-roll-commercial-routing-reqs-00.txt,.pdf>
The ROLL Working Group was recently chartered by the IETF to define
routing characteristics for low power embedded devices. ROLL would like
to serve the Industrial, Commercial, Home and Urban markets. Pursuant to
this effort, this document defines the functional and cost requirements
for installing integrated facility management systems in commercial
facilities.
The routing requirements for commercial building applications are
presented in this document. Commercial buildings have been fitted with
pneumatic and subsequently electronic communication pathways connecting
Martocci
Expires January 14, 2009
[page 1]
Internet-Draft draft-martocci-roll-commercial-routing-reqs
July 2008
sensors to their controllers for over one hundred years. Recent economic
and technical advances in wireless communication allows facilities to
increasingly utilize a wireless solution in lieu of a wired solution;
thereby reducing installation costs yet maintaining highly reliant
communication. Wireless solutions will be adapted from their existing
wired counterparts in many of the building applications including, but
not limited to HVAC, lighting, security, fire, and elevator products.
These devices will be developed to reduce installation costs; while
increasing installation and retrofit flexibility. Sensing devices may be
battery or mains powered. Actuators and area controllers will be mains
powered.
To meet the cost target, these devices must have a total installed cost
below that of the traditional wired alternative; yet maintain reliability
on par with wired devices. The total installed cost includes the
infrastructure, product, installation, commissioning, labor and
operational costs of the device over its 30 year lifespan. Except for
special circumstances such as flexible installation (e.g. airports) or
cosmetics (e.g. museums, there is nothing compelling about installing
wireless solutions inside a building unless it can be accomplished below
the cost of a wired installation. This document will define the
requirements necessary for wireless technology to displace wired
infrastructure and meet this objective.
"Faster application handshakes with SYN/ACK payloads", Adam Langley,
5-Aug-08, <draft-agl-tcpm-sadata-01.txt>
This document advocates the usage of small, mostly constant payloads
in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show
how this can have immediate benefits for some protocols.
Additionally, we describe a new TCP option that enables a wider range
of protocols to gain from it.
"User centric QoS policy management for heterogeneous Internet environment",
Ilka Miloucheva, Irit Sterdiner Mayer, P.A. Aranda Guiterrez, Adam
Flizikowski, Christophe Chassot, 18-Jul-08,
<draft-miloucheva-user-policy-00.txt>
This document presents a framework for user-centric Quality of
Service (QoS) management in heterogeneous Internet environments
(considering fixed, mobile and broadcast networks).
The framework is based on dynamic business level QoS policy
specification by different actors (such as users, operators
and administrators), as well as hierarchical policy refinement
and translation, supporting the automated configuration of QoS
mechanisms at heterogeneous network and transport entities.
The hierarchical policy approach involves abstractions and mapping
of policies described at business, unified, operational and
configuration level considering networks with different capabilities
and QoS requirements of different actors.
The policy specification is dependent on the Service
Level Agreements (SLAs) of the particular actors.
This allows controlled and restricted usage of the network
resources by the actors according to the actor dependencies and
corresponding SLA rules.
The policy management framework includes components for dynamic
actor-based QoS policy specification, policy consistency check
and dependency analysis regarding SLAs, automated policy
provisioning and configuration at heterogeneous transport and
network entities, policy monitoring and performance
assessment, as well as automated adaptation of QoS mechanisms at
operational level.
Policy enforcement combined with policy monitoring and performance
assessment is considered, as well as automated adaptation of
policy parameters (e.g. operational policies) based on policy
performance analysis.
Interactions of components for policy specification and automated
provisioning are based on policy repository storing the unified
(intermediate) policy representations describing policy parameters,
conditions and actions.
"Border Router Discovery Protocol (BRDP) based Address Autoconfiguration",
Teco Boot, Arjen Holtzer, 1-Nov-08, <draft-boot-autoconf-brdp-01.txt>
Mobile Ad hoc Networks (MANET) may be attached to a fixed
infrastructure network, like the Internet. This document specifies a
mechanism for Border Router discovery and utilization in such a
subordinate, possibly multi-homed, MANET. It provides facilities for
choosing preferred Border Router(s) and configuring IP address(es)
needed for communication between MANET nodes and nodes on the
Internet via the selected Border Router. Autonomous MANETs do not
have Border Routers; an self-sufficient Address Autoconfiguration is
defined as well.
"A CGA based Source Address Authorization and Authentication (CSA) Mechanism
for First IPv6 Layer-3 Hop", Jun Bi, Jianping Wu, Guang Yao, 27-Jul-08,
<draft-bi-savi-csa-00.txt>
This document describes a method to authorize and authenticate the
address of a node in an IPv6 network. Except for "Host Change", this
method satisfies all the requirements in the Charter of SAVI. The
modification on a host can be regarded as the extension of SEND and
IPSec.
"Specifying Derived Location in a PIDF-LO", James Winterbottom, Martin
Thomson, 27-Jul-08, <draft-winterbottom-geopriv-derived-loc-00.txt>
This document describes how specify that a location in a PIDF-LO has
been derived or converted from a different location. The source
location may reside in the same PIDF-LO or be a remote document
referenced by a location URI and associated id fragement.
"Advertisement of the best-external route to IBGP", Pedro Roque Marques, Rex
Fernando, Enke Chen, Pradosh Mohapatra, 27-Jul-08,
<draft-marques-idr-best-external-00.txt>
This document makes a case and provides the rules for a border router
to advertise its best external route towards its IBGP peers when its
overall best is a route received from an IBGP peer.
The best external route may be different from the overall best route
installed in the Loc-Rib. Advertising the best-external route (when
different from the overall best route) into an IBGP helps in speeding
up routing convergence, has positive effects in reducing inter-domain
churn and in some limited scenarios could help avoid permanent IBGP
route oscillation.
The document also extends this mechanism to route reflectors and
confederation border routers to advertise a best route that is
external to the cluster/domain.
"FTP Extension Registry", John Klensin, 27-Jul-08,
<draft-klensin-ftp-registry-00.txt>
Every version of the FTP specification has added a few new commands,
with the early ones summarized in RFC 959. RFC 2389 established a
mechanism for specifying and negotiating FTP extensions. As the
number of those extensions increases, it appears useful to establish
an IANA registry to reduce the likelihood of conflict of names and
the consequent ambiguity. This specification establishes that
registry.
"FTP Extension for Internationalized Text", John Klensin, 27-Jul-08,
<draft-klensin-ftp-typeu-00.txt>
The original FTP protocol supported TYPE values for ASCII and EBCDIC
text, plus binary ("IMAGE") transmission. As the Internet becomes
more international, there is a growing requirement to be able to
transmit textual data, encoded in Unicode, in a way that is
independent of the coding and line representation forms of particular
operating systems. This memo specifies a new FTP TYPE value for
Unicode data.
"Location and Discovery of Subsets of Resources", Lican Huang, 27-Jul-08,
<draft-licanhuang-p2psip-subsetresourcelocation-00.txt>
This file is a proposal for location and discovery of filter
resources selected by search-conditions. The peers,which are
virtually grouped, construct n-tuple overlay virtual hierarchical
tree overlay network. With cached addresses of peers, the overload of
traffic in tree structure can be avoided. The resources are
classified into hierarchical domains, and registered into the peers
which are located in the same domain virtual groups as the
resources'. This proposal supports flexible queries by a SQL-like
query statement.
"Textual Representation of AS Numbers", George Michaelson, Geoff Huston,
28-Jul-08, <draft-michaelson-as-representation-00.txt>
A textual representation for Autonomous System (AS) numbers is
defined using "asdot" notation. This textual representation is to be
used by all documents, systems and user interfaces referring to AS
numbers.
"Textual Representation of AS Numbers", Geoff Huston, George Michaelson,
28-Jul-08, <draft-huston-as-representation-00.txt>
A textual representation for Autonomous System (AS) numbers is
defined as the decimal value of the AS Number. This textual
representation is to be used by all documents, systems and user
interfaces referring to AS numbers.
"Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks",
Jonathan Hui, 28-Jul-08, <draft-hui-6lowpan-nd-00.txt>
This document specifies a simple version of IPv6 Neighbor Discovery
for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover
routers, discover network configuration parameters, and IPv6 prefixes
for use with stateless address autoconfiguration and context-based
6LoWPAN compression for IPv6 headers. This document also specifies
autoconfiguration mechanism for use in 6LoWPAN networks.
"Capabilities Update Problem Statement", Tina Tsou, 28-Jul-08,
<draft-tsou-dime-capabilities-update-statement-00.txt>
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis. Capabilities update in OPEN state can reuse
commands CER/CEA commands for re-negotiation between Diameter peers
when one of them changes its capabilities.It is a very important
function in Diameter.
However, RFC 3588 has defined a mechanism of containing capabilities
list both in CER and CEA commands and the peer should update its
local database whenever it receives CER/CEA. This makes the process
complex and redundant when they are used in OPEN state. So this
draft proposes a simpler solution based on CER/CEA commands to deal
with this problem.
"EDNS0 Support in Authority Servers on 27 July 2008", Shane Kerr, Joe Abley,
28-Jul-08, <draft-kerr-dnsop-edns0-penetration-00.txt>
This memo documents the methodology and results of an experiment
which tested the availability of the DNS Extension Mechanism (EDNS0)
on a large set of authority-only nameservers. The experiment was
conducted in the bar during the IETF 72 meeting on 27 July 2008.
The results of this experiment suggest that EDNS0 deployment is
extensive: it was found that 94.4% of non-defective authority-only
servers are EDNS0-capable.
"Incentives and Deployment Considerations for P2PI Solutions", Jari Arkko,
29-Jul-08, <draft-arkko-p2pi-incentives-00.txt>
Several papers in the May 2008 P2PI workshop have argued that there
is a need to build new protocol mechanisms to accommodate peer-to-
peer traffic in networks in the most efficient way and with minimal
impact to other traffic. This paper presents an analysis of such
solutions from the point of view of the incentives of the different
parties involved in peer-to-peer traffic. The paper concludes that
it is essential to understand the incentives in order to have a
deployable solution.
"Requirements for handling abandoned calls and premature disconnects in
emergency calls on the Internet", Brian Rosen, 3-Nov-08,
<draft-rosen-ecrit-premature-disconnect-rqmts-01.txt>
The -phonebcp draft currently requires endpoints to disable sending a
BYE on an emergency call. Insufficient justification and lack of
attention to the entire problem has caused comment on that section of
the document. This document attempts to define the problem and the
requirements to controlling disconnect on emergency calls.
"MSWS Method to Support Shared-Mesh Restoration for Wavelength Switched
Optical Networks", Lin Guo, Yuefeng Ji, Hongxiang Wang, 29-Jul-08,
<draft-ji-ccamp-wson-msws-00.txt>
This document proposes a method called Most Sharable Wavelength per
Segment (MSWS) to support shared-mesh restoration for wavelength
switched optical networks (WSON). The proposed method can perform
efficient wavelength sharing in a distributed fashion. It uses the
signaling extensions for WSON which is previously proposed in the
document "Signaling Extensions for Wavelength Switched Optical
Networks" (draft-bernstein-ccamp-wson-signaling-01) and no other
protocol extensions of Generalized Multi-Protocol Label Switching
(GMPLS) routing and signaling are needed.
"HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-
layer Protocol Signaling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan
Melen, 3-Nov-08, <draft-nikander-hip-hiccups-01.txt>
This document defines a new HIP (Host Identity Protocol) packet type
called DATA. HIP DATA packets are used to securely and reliably
convey arbitrary protocol messages over the Internet and various
overlay networks.
"Remote Triggered Black Hole filtering with uRPF", Warren Kumari, Danny
McPherson, 29-Oct-08, <draft-kumari-blackhole-urpf-02.txt>
Remote Triggered Black Hole (RTBH) filtering is a popular and effective
technique for the mitigation of denial of service attacks. This document
expands upon destination-based RTBH filtering by outlining a method to
enable filtering by source address as well. It also defines a standard
BGP community for black hole prefixes to simplify associated semantics.
"IESG Procedures for Handling of Independent and IRTF Stream Submissions",
Harald Alvestrand, Russ Housley, 19-Nov-08,
<draft-housley-iesg-rfc3932bis-06.txt>
This document describes the procedures used by the IESG for handling
documents submitted for RFC publication on the Independent and IRTF
streams.
This document updates procedures described in RFC 2026 and RFC 3710.
"Dynamic Host Configuration Protocol Option for Softwires", David Hankins,
11-Aug-08, <draft-dhankins-softwire-tunnel-option-01.txt>
This document describes how Softwires configuration can be obtained
via DHCPv6.
"Application Extension Bundle description Language (AEBL)", Trevor Clarke,
31-Jul-08, <draft-tclarke-aebl-00.txt>
This memo presents an RDF [refs.RDF] vocabulary for describing an
application extension bundle [refs.aeb]. An application extension
bundle, otherwise known as an add-on, extension, plug-in, suite, or
package, is an encapsalation of all the data needed to add
functionality to a plug-in based application. An integral piece of
an application extension bundle is the metadata describing the
bundle. The described RDF vocabulary contains required and optional
metadata fields used by an application extension bundle to describe
itself.
"Application Extension Bundle (AEB)", Trevor Clarke, 31-Jul-08,
<draft-tclarke-aeb-00.txt>
This memo presents a file format for describing an application
extension bundle. An application extension bundle, otherwise know as
an add-on, extension, plug-in, suite, or package, is an encapsalation
of all the data needed to add functionality to a plug-in based
application.
"Guidance on Interoperation and Implementation Reports", Lisa Dusseault,
Robert Sparks, 31-Jul-08, <draft-dusseault-impl-reports-00.txt>
Advancing a protocol to Draft Standard requires documentation of the
interoperation and implementation of the protocol. Historic reports
have varied widely in form and level of content and there is little
guidance available to new report preparers. This document updates
the existing processes and provides more detail on what is
appropriate in an interoperability and implementation report.
"Nest Route Optimization for NEMO (NERON)", Faqir Zarrar Yousaf, Christian
Wietfeld, Alain Tigyo, 21-Aug-08, <draft-yousaf-ietf-nemo-neron-01.txt>
IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support
protocol that handles the mobility management of IPv6 based mobile
networks. However the NEMO protocol has severe performance
limitations and does not specify the route optimization method for mobile
networks and does not take into account the operational and functional complexities
involving nested mobile networks.
In this draft we present NEst Route Optimization for NEMO (NERON)
protocol, a light weight, efficient and scalable approach that aims
at enabling nodes behind nested mobile networks to use optimized
communication paths with zero tunneling overhead and minimum end-to-
end delay, irrespective of the depth of the nest, with minimum but
manageable changes to the base MIPv6 and IPv6 Neighbor Discovery
protocols and without introducing any new network entities.
"The Expires Header in E-mail", Michael Welzl, Thomas Nolf, Jacob Palme,
4-Aug-08, <draft-welzl-expires-00.txt>
This memo introduces a new email header called Expires. Using this
header, the sender of an email can state that (s)he believes this
message will be irrelevant after the indicated date/time. The
receiving MUA can then automatically detect that a message has
expired and facilitate handling of such emails for the user.
"IPv6 Path MTU computation using routing protocol", Vijay Kumar Vasantha,
4-Aug-08, <draft-kumar-ipv6-pmtu-using-routing-proto-00.txt>
This document describes a mechanism for dynamically computing IPv6
PMTU and the modifications needed in IPv6 to support the solution.
"ISIS: Path MTU calculation in ISIS", Vijay Kumar Vasantha, 4-Aug-08,
<draft-kumar-isis-path-mtu-00.txt>
This draft defines a method for calculating the PMTU for each IPv6
destinations using ISIS routing protocol. By doing so the overhead
incurred in the existing path maximum transferable unit discovery
mechanism is reduced and the same solution can be extended to other
link state routing protocols as well.
"SASL Mechanism for External Authentication using Channel Bindings:
EXTERNAL-CHANNEL", Simon Josefsson, 5-Aug-08,
<draft-josefsson-sasl-external-channel-00.txt>
This document describes a way to perform end-user authentication in
the Simple Authentication and Security Layer (SASL) framework which
re-use an external security layer (such as the Transport Layer
Security (TLS) protocol) that may have already completed end-user
authentication. In comparison with the existing EXTERNAL mechanism,
this mechanism offers a way to cryptographically bind the
authentication to the security layer via a channel binding. The
EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made
by the design of the EXTERNAL mechanism.
See <http://josefsson.org/external-channel/> for more information.
"MLD Extensions to Support the Mobile Multicast Group Management", Hong-Ke
Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan, 5-Aug-08,
<draft-zhang-multimob-mld-mmcast-00.txt>
Mobile multicast is a research hotspot. Some mobile multicast schemes
was proposed, but most of them depend on the traditional group
membership management protocol and concern on the reconstruction of multicast
delivery tree by various algorithms, and they little consider the mobile
group membership management. So in this memo, we extend the MLD protocol
to support the mobile multicast group management. The extension is compatible
with the traditional MLD protocols, and it can also be applied to the IGMP
protocol to manage the mobile multicast in IPv4.
"Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08,
<draft-moreau-pkix-aixcm-00.txt>
The Transport Layer Security (TLS) protocol does not support the use
of client public key pairs without X.509 security certificates. This
document circumvents this limitation: an end-entity has access to
the public domain private key of a dummy (or "explicitly
meaningless") Certification Authority (CA), and can thus freely
issue an X.509 security certificate for interoperability purposes.
Given these workaround requirement and solution approach, the
document limits itself to the strict minimal set of standardization
provisions. This supports the orderly cohabitation of auto issued
certificates and normal TLS traffic relying on the full Public Key
Infrastructure (PKI) model.
"Problems observed with RSVP recovery signaling", Andrew Rhodes, Nic Neate,
David McWalter, 6-Aug-08, <draft-rhodes-rsvp-recovery-signaling-00.txt>
Implementation experience with RSVP-TE recovery signaling has
uncovered some problems. Associations between LSPs in different
sessions are forbidden. Protecting LSPs cannot themselves be
protected. Overlapping repairs cause loss of traffic. This draft
provides details of these problems for the community to consider.
"A DNS Resource Record for Additional Entropy", Jim Reid, 6-Aug-08,
<draft-reid-dnsext-aleatoric-00.txt>
A scheme to defend against cache poisoning attacks against the Domain
Name System (DNS) by predicting the ID and source port number of
outgoing queries is described in this draft. It proposes a new
resource record to provide a mechanism to introduce additional
entropy into DNS queries.
"Translator Friendly DNS Proxy", Masahito Endo, Hiroshi Miyata, 1-Oct-08,
<draft-endo-v6ops-dnsproxy-01.txt>
This document describes the DNS Proxy that is separated from NAT-PT
[RFC2766]. NAT-PT was designed to work with DNS Application Level
Gateway. However [RFC4966] pointed out DNS related issues, and
[RFC2766] was changed to historical state. This document attempts to
DNS Proxy specification, removing dependency on NAT-PT as well as
resolving problems pointed in [RFC4966].
"DKIM Author Domain Signing Practices (ADSP) Security Issues", Douglas Otis,
30-Sep-08, <draft-otis-dkim-adsp-sec-issues-03.txt>
The proposed [I-D.ietf-dkim-ssp] defines DNS records that advertise
the extent to which a domain employs [RFC4871] to sign [RFC2822]
messages, and defines how other hosts can access these
advertisements. Its laudable goal is to allow domains control over
the use of the From header field. When a message is not adequately
signed, advertised assertions, referenced by a domain in the From
header field, assist in resolving the message's intended disposition.
Rather than dealing with keys that impose a restriction on the "on-
behalf-of" identity as a separate security consideration to be
handled independently from an assertion that a domain signs their
messages, [I-D.ietf-dkim-ssp] instead employs a flawed two-stage
signature validation process that works in conjunction with
advertised practices. The two-stage approach will most likely occur
after message acceptance, and impairs the range of authentication
assertions permitted by a single signature. The limitations on
authentication assertions inhibits tactics needed to deal with replay
abuse.
As currently structured, advertised practices not only assert whether
a signature should be expected, they also constrain the
"on-behalf-of" identity applied by signing agents that are not
otherwise so restricted by [RFC4871]. By constraining the "on-
behalf-of" identity for all signing agents, the draft neglects the
predominate role of the domain as a point of trust, and incorrectly
assumes the signature is limited to supporting assertions regarding
the identity of the author. By limiting the DKIM signature's "on-
behalf-of" value to being representative of only the message's
author, the draft goes well beyond the working group's charter and
appears to infringe on S/MIME's and OpenPGP's role.
[I-D.ietf-dkim-ssp] impairs security in other ways as well, such as
the only directly actionable practice is defined using a term likely
to negatively impact the integrity of delivery status. Fortunately
minor changes to the definition of a compliant signature can remedy
the impairment created, where the critical security issues are best
handled independent of any [I-D.ietf-dkim-ssp] assertion.
"New Tunnel-Type Values", Abhishek Tiwari, 29-Aug-08,
<draft-tiwari-radext-tunnel-type-02.txt>
This document defines a set of values for the Tunnel-Type RADIUS
Attribute.
"Kerberos ticket extensions", Love Astrand, 14-Sep-08,
<draft-lha-krb-wg-ticket-extensions-02.txt>
The Kerberos protocol does not allow ticket extensions. This make it
harder to deploy features like referrals and PKCROSS.
Since the Kerberos protocol did not specified extensibility for the
Ticket structure and the current implementations are aware of the
contents of tickets, the extension protocol cannot simply extend the
Ticket ASN.1 structure. Instead, the extension data needs to be
hidden inside the ticket.
This protocol defines two methods to add extend the tickets. The
first method requires updated clients and is more in line with the
future development of Kerberos. The second way does not require
update client. To take advantage of this protocol the server (KDC or
application server) need to update a well. The two methods are
equivalent and there is a 1-1 mapping between them.
"GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman,
23-Sep-08, <draft-lha-gssapi-delegate-policy-01.txt>
Several GSS-API applications work in a multi-tiered architecture,
where the server takes advantage of delegated user credentials to act
on behalf of the user and contact additional servers. In effect, the
server acts as an agent on behalf of the user. Examples include web
applications that need to access e-mail or file servers as well as
CIFs file servers. However, delegating the ability to act as a user
to a party who is not sufficiently trusted is problematic from a
security standpoint. Kerberos provides a flag called OK-AS-DELEGATE
that allows the administrator of a Kerberos realm to communicate that
a particular service is trusted for delegation. This specification
adds support for this flag and similar facilities in other
authentication mechanisms to GSS-API (RFC 2743).
"ECC Support for SEND/CGA", Sean Shen, Michaela Vanderveen, 10-Oct-08,
<draft-shen-csi-ecc-01.txt>
This draft proposes an upgrade to the SEND/CGA protocols to
incorporate support for elliptic curve cryptography.
"Approach to Digital Signature Systems Deployment", John Marchioni, Yair
Itzhaki, 14-Aug-08, <draft-marchioni-itzhaki-ds-system-deployment-00.txt>
Most digital-signature system deployments require dedicated and
solution-specific user-enrollment procedures and user-enrollment
software[1], and mandate provisioning and distribution of physical or
software-based signature-key tokens to end users. As deployed such
approaches create a high burden in logistics, cost, and help-desk
support. They also introduce training obstacles for users and
systems administrators.
This document describes the deployment architecture approach used by
ARX to provide secure and efficient digital signature services based
on its CoSign(r) solution. The security solution's deployment
architecture is documented in the hope that other digital-signature
and PKI deployment efforts will deliver comparable efficiencies.
[1] This is also true for deployments of non-standard proprietary
electronic signature solutions.
"OpenPGP Attribute Extension", Duane Groth, 14-Aug-08,
<draft-groth-openpgp-attribute-extension-00.txt,.pdf>
A RFC was accepted extending TLS usage to include OpenPGP keys (RFC
5081) as an alternative or in addition to X.509 certificates,
however the author did not really standardise the way the
information in OpenPGP keys was to be presented and this could be
detrimental or fragment efforts to utilise OpenPGP keys in this
manner.
The author didn't touch on the issue generating confidence scores
beyond potential use of Certificate Authorities.
"Applicability of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP)
Headers", Julian Reschke, 15-Aug-08, <draft-reschke-rfc2231-in-http-00.txt>
By default, message header parameters in Hypertext Transfer Protocol
(HTTP) messages can not carry characters outside the ISO-8859-1
character set. RFC 2231 defines an escaping mechanism for use in
Multipurpose Internet Mail Extensions (MIME) headers. This document
specifies a profile of that encoding suitable for use in HTTP.
"EDNS Option for performing a data PING", Bert Hubert, David Ulevitch,
17-Aug-08, <draft-hubert-ulevitch-edns-ping-00.txt>
For various reasons, it may be desireable to ask a remote nameserver
to add certain data to the response to a query.
This document describes an EDNS option that implements such
behaviour.
"PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Arnaud
Ebalard, Sebastien Decugis, 18-Aug-08,
<draft-ebalard-mext-pfkey-enhanced-migrate-00.txt>
This document describes the need for an interface between Mobile IPv6
and IPsec/IKE and show how the two protocols can interwork. An
extension of the PF_KEY framework is proposed which allows smooth and
solid operation of 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 address
information for both the in-kernel IPsec structures (SP/SA) and those
maintained by the key managers. This includes in-kernel SP/SA
endpoints, key manager maintained equivalents and addresses used by
IKE_SA (current and to be negotiated). The extension is helpful for
assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for
the bootstrapping of mobile nodes and their movements.
"Alert-Info header URNs for Session Initiation Protocol (SIP)", Denis
Alexeitsev, 2-Sep-08, <draft-alexeitsev-bliss-alert-info-urns-01.txt>
The Session Initiation Protocol (SIP) supports the capability to
provide a reference to the alternative ringback tone (RBT) for
caller, or ring tone (RT) for callee using the Alert-Info header.
However, the reference addresses only the network resources with
specific rendering properties. There is currently no support for
predefined standard identifiers for ringback tones or semantic
indications without tied rendering. To overcome this limitations and
support new applications a family of the URNs is defined in this
specification.
"Ivip4 ETR Address Forwarding", Robin Whittle, 22-Aug-08,
<draft-whittle-ivip4-etr-addr-forw-01.txt>
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.
Consequently, packets in this format need to be handled by routers
with modified functionality. EAF is an alternative to encapsulation
(map-encap) or address translation (Six/One Router) 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.
"Neighbor Discovery Suppression", Laurent Toutain, Guillaume Chelius,
Yoongsoo Lee, Yongqiang DONG, 20-Aug-08,
<draft-toutain-6lowpan-ra-suppression-00.txt>
The 6LoWPAN IETF working group is developing protocols to allow IPv6
end-to-end communication with sensors networks. Low-power MAC
protocols such as IEEE 802.15.4 impose a slightly reduced frame size.
To enable IPv6 communication, 6LoWPAN proposes to use fragmentation
and header compression techniques. This document proposes an
extension to the 6LoWPAN proposal and defines a class of sensors that
can be joined at the network level while ignoring their own global
IPv6 address. This architecture centralizes the address management
on the sensor network gateway (the PAN Coordinator) and allows the
suppression of the Neighbor Discovery Protocol. Consequently, the
insertion of sensors in such a network is faster and the traffic
within the network, largely composed of broadcast messages generated
by Neighbor Discovery Protocol, is reduced. We investigate the
impact of this architecture on star and mesh topologies.
"Rbridge Notes", Donald Eastlake 3rd, 20-Aug-08,
<draft-eastlake-trill-rbridge-notes-00.txt>
This document provides additional informational material related to
RBridges, which are devices that implement the TRILL protocol. It is
a supplement to the RBridges base protocol specification and includes
discussion of tradeoffs in some features and configurations of
RBridges. In addition, it provides a sketch of a proof that, with
reasonable assumptions, persistent loops do not occur in a TRILL
campus.
"Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6",
Hidetoshi Yokota, Sri Gundavelli, Kent Leung, 21-Aug-08,
<draft-yokota-netlmm-pmipv6-mn-itho-support-00.txt>
Proxy Mobile IPv6 supports a handoff between different access
technologies, by which the assigned IP address is preserved
regardless of the access technology type. From the perspective of
the mobile node, this involves the change of the network interfaces,
through which the IP address is assigned and the IP session is
established. Some implementations, however, do not assume this
interface switching in the middle of the session and it could cause a
disconnection by the event of unavailability of the current
interface; hence it is not guaranteed to be able to maintain the IP
session simply by assigning the same IP address to the new interface.
This document analyzes the handling of the network interfaces on the
mobile node and presents several measures to avoid a disconnection
due to the interface switching.
"IP and ARP over Wiegand", Scott Guthery, 22-Aug-08,
<draft-guthery-wiegand-ip-00.txt>
This document describes the transport of IP datagrams over the
Security Industry Association standard [3] five-conductor cable
called the Wiegand interface used for communication between card
readers and control panels in physical access control systems.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"Images in RFCs", Robert Braden, John Klensin, 25-Sep-08,
<draft-rfc-image-files-01.txt>
Documents in the RFC series normally use only plain-text ASCII
characters and a fixed-width font. However, there is sometimes a
need to supplement the ASCII text with graphics or picture images.
The historic solution to this requirement, allowing secondary PDF and
Postscript files, is seldom used because it is awkward for authors
and publisher. This memo sugests a more convenient scheme for
attaching authoritative diagrams, illustrations, equations or other
graphics to RFCs.
"Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications",
David Hankins, 22-Aug-08, <draft-dhankins-dhcpinform-clarify-00.txt>
The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the previously defined standard, and some
questions about DHCPv4 server behaviour remain unclear.
"The Metalink Download Description Format", Anthony Bryan, 18-Sep-08,
<draft-bryan-metalink-03.txt>
This document specifies Metalink Documents, an XML-based download
description format.
"Security Assessment of the Internet Protocol version 4", Fernando Gont,
31-Aug-08, <draft-gont-opsec-ip-security-01.txt>
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).
"Resolver side mitigations", Wouter Wijngaards, 25-Aug-08,
<draft-wijngaards-dnsext-resolver-side-mitigation-00.txt>
Describes a set of mitigations that stop the known Kaminsky
variations, for which only resolver side deployment is necessary.
"EDNS EXPIRE OPTION", Mark Andrews, 25-Aug-08,
<draft-andrews-dnsext-expire-00.txt>
Provide a method for slave DNS servers to honour the SOA EXPIRE field
as if they were always transferring from the master, even when using
other slaves to perform indirect transfers and refresh queries.
"With-defaults capability for NETCONF", Andy Bierman, Balazs Lengyel,
22-Oct-08, <draft-bierman-netconf-with-defaults-01.txt>
The NETCONF protocol defines ways to read configuration data from a
NETCONF agent. Part of this data is not set by the NETCONF manager,
but rather a default value is used. In many situations the NETCONF
manager has a priori knowledge about default data, so the NETCONF
agent does not need to send it to the manager. In other situations
the NETCONF manger will need this data as part of the NETCONF rpc
reply messages. This document defines a capability-based extension
to the NETCONF protocol that allows the NETCONF manager to control
whether default values are part of NETCONF rpc reply messages.
"Media Format Choices for RFCs", Dave Crocker, 27-Aug-08,
<draft-crocker-rfc-media-00.txt,.pdf>
Documents in the RFC series normally use only plain-text ASCII
characters and a fixed-width font. However, there is sometimes a
need to supplement the ASCII text with graphics or picture images.
The historic solution to this requirement, allowing secondary PDF and
Postscript files, is seldom used because it is awkward for authors
and publisher. This memo suggests a more convenient scheme for
attaching authoritative diagrams, illustrations, or other graphics to
RFCs. It further proposes conventions for additional input and
display formats, to improve readability. This proposal is based on
draft-rfc-image-files-00, by Braden and Klensin, and revises it as
little as possible, while expanding the goals of the effort.
"Transport Layer Security (TLS) Authorization Using KeyNote", Angelos
Keromytis, 1-Oct-08, <draft-keromytis-tls-authz-keynote-01.txt>
This document specifies the use of the KeyNote trust-management
system as an authorization extension in the Transport Layer
Security (TLS) Handshake Protocol, according to [AUTHZ].
Extensions carried in the client and server hello messages
confirm that both parties support the desired authorization
data types. Then, if supported by both the client and the
server, KeyNote credentials are exchanged during the
supplemental data handshake message.
"Spam reduction using messageid.", Mark Turner, 27-Sep-08,
<draft-turner-antispam-using-messageid-01.txt>
This draft suggests a technique of spam reduction by extending the
SMTP service to include a 'Did You Send' query protocol.
"An Architecture for Network Management", Philip Shafer, 4-Sep-08,
<draft-shafer-netmod-arch-00.txt>
NETCONF and YANG are pieces of an ambitious plan to improve network
management. NETCONF gives access to native capabilities of the
devices within a network, defining methods for manipulating
configuration databases, retrieving operational data, and invoking
specific operations. YANG provides the means to define the content
trafficked via NETCONF, both data and operations. Using both
technologies, the standards modules can be defined to give
interoperability and commonality to devices, while still allowing
devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network
management applications that meet the needs of network services
providers. An architecture is described which is friendly to both
devices and applications, to vendors and standards bodies, to young
and to old, to red states and to blue states. It's a startling
vision, coming to networks near you starting August, 2009.
"Multicast Routing in Proxy Mobile IPv6", Hong-Ke Zhang, Jian-feng Guan,
Hua-chun Zhou, ying zhu, 4-Sep-08, <draft-zhang-netlmm-pmipv6-mcast-00.txt>
With the development of various mobile technologies, mobile multicast becomes
a research hotspot. Several mobile multicast schemes were proposed, but most
of them are based on the Mobile IPv6 and its alternatives. Recently, the
Proxy Mobile IPv6 (PMIPv6) was proposed to provide the mobility support for
mobile node without mobility function. However, the PMIPv6 mainly concerns
on the unicast transmission support, and little considers the multicast routing.
So, in this memo, we propose two mobile multicast mechanisms, the MAG- based
method and LMA-based method to support the multicast routing in PMIPv6.
"Never Ending Network Addresses: IPv4 Multiplexing trought IPv6", Alessandro
Spinella, 5-Sep-08, <draft-nena-ip4-ip6-mux-00.txt>
While the wide use of IPv4 "private" addresses [RFC1918] lead to a
great flexibilty degree of uninterconnected networks and use of IPv6
offer a huge address space; no "nice" mechanism exist to hide overlap
of existing IPv4 "private" networks if and when the sum of used
address spaces is greater than the IPv4 "private" address space.
This document specifies how to walk around the matter without any
coordination, renumbering or IPv6 adoption by overlapping networks
owners.
"Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol
Specifications", Adrian Farrel, 1-Nov-08,
<draft-farrel-rtg-common-bnf-07.txt>
Several protocols have been specified using a common variant of the
Backus-Naur Form (BNF) of representing message syntax. However, there
is no formal definition of this version of BNF.
There is value in using the same variant of BNF for the set of
protocols that are commonly used together. This reduces confusion and
simplifies implementation.
Updating existing documents to use some other variant of BNF that is
already formally documented would be a substantial piece of work.
This document provides a formal definition of the variant of BNF that
has been used (that we call Reduced BNF), and makes it available for
use by new protocols.
"Resolver side mitigations", George Barwood, 26-Oct-08,
<draft-barwood-dnsext-fr-resolver-mitigations-08.txt>
Describes mitigations against spoofing attacks on DNS, including:
(1) Repeating the query, including techniques for handling
non-deterministic responses.
(2) Prepending a random nonce to the question where a referral is
probable.
(3) Estimating the entropy available, taking into account
(a) Observed packets with incorrect IDs.
(b) The content of the cache.
"RTP Payload Format for Portable Network Graphics (PNG) image", Omer Boyaci,
Henning Schulzrinne, 8-Sep-08, <draft-boyaci-avt-png-00.txt>
This document describes how to carry Portable Network Graphics (PNG)
images in RTP packets.
"Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", Vishwas Manral, 8-Sep-08,
<draft-manral-mpls-rfc3811bis-00.txt>
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. This document updates RFC3811 and fixes the .
"Encapsulation Methods for Transport of InfiniBand over MPLS Networks",
Suresh Shelvapille, Vikas Puri, 8-Sep-08, <draft-puri-pwe3-ib-encap-00.txt>
An InfiniBand(IB) pseudowire (PW) is used to carry InfiniBand
frames over an MPLS network. This enables service providers to
offer "emulated" InfiniBand services over existing MPLS networks.
This document specifies the encapsulation of InfiniBand PDUs within
a pseudowire. It also specifies how islands of IB fabrics can be
connected via PWs to form a single IB subnet.
"In-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria
Napierala, 8-Sep-08, <draft-wijnands-mpls-in-band-signaling-00.txt>
When an IP multicast tree needs to pass through an MPLS domain, it is
advantageous to map the tree to a Point-to-Multipoint or Multipoint-
to-Multipoint Label Switched Path. This document specifies a way to provide
a one-one mapping between IP multicast trees and Label Switched Paths. The
IP multicast control messages are translated into MPLS control messages when
they enter the MPLS domain, and are translated back into IP multicast control
messages at the far end of the MPLS domain. The IP multicast control information
is coded into the MPLS control information in such a way as to ensure that
a single Multipoint Label Switched Path gets set up for each IP multicast
tree.
"Link Connectivity and Common Constraint Information Extension to GMPLS for
WDM Switched Optical Networks", Zhihong Kang, Zhenyu Wang, Feng Gao,
9-Sep-08, <draft-kang-ccamp-wdm-switch-info-00.txt>
This document provides the mechanism of link connectivity
verification and the constraint information extension to GMPLS IGP or
Conveyed to a path computation element (PCE) for static light path
computation and selection in WDM network.
"Building Automation Routing Requirements in Low Power and Lossy Networks",
Jerry Martocci, Nicolas Riou, Pieter Mil, Wouter Vermeylen, 14-Oct-08,
<draft-martocci-roll-building-routing-reqs-01.txt>
The Routing Over Low power and Lossy network (ROLL) Working Group has
been chartered to work on routing solutions for Low Power and Lossy
networks (LLN) in various markets: Industrial, Commercial (Building),
Home and Urban. Pursuant to this effort, this document defines the
routing requirements for building automation.
"AS Number Reservation for Documentation Use", Geoff Huston, 10-Sep-08,
<draft-huston-as-documentation-reservation-00.txt>
To reduce the likelihood of conflict and confusion when relating
documented examples to deployed systems, two blocks of Autonomous
System numbers (ASNs) are reserved for use in examples in RFCs,
books, documentation, and the like. This document describes the
reservation of two blocks of ASNs as reserved numbers for use in
documentation.
"A Session Initiation Protocol (SIP) Event Package for Communication
Diversion Information", Samir Saklikar, Subir Saha, Ranjit Avasarala,
10-Sep-08, <draft-saklikar-comm-diversion-notification-00.txt>
This draft defines a Session Initiation Protocol (SIP) Event
Notification Framework-based mechanism for notifying Users about
diversions (re-directions or forwarding) of their incoming
communication sessions. A new event package is proposed for allowing
users to subscribe for and receive such notifications. Users have
further capability to define filters controlling the selection, rate
and content of such notifications. The applicability of this event
package includes 3GPP IMS.
"Suite B Cryptographic Suites for Secure Shell", Kevin Igoe, 11-Sep-08,
<draft-igoe-secsh-suiteb-00.txt>
This document describes the basic architecture of a Suite B compliant
implementation of the Secure Shell Transport Layer Protocol. Suite B
secure shell makes use of elliptic curve Diffie-Hellmann (ECDH) key
agreement, the elliptic curve digital signature algorithm (ECDSA),
the Advanced Encryption Standard running in Galois Counter Mode
(AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and
SHA-384), and X.509 certificates.
"SOS Uniform Resource Identifier (URI) parameter for marking of Session
Initiation Protocol (SIP) requests related to emergency services", Milan
Patel, 3-Nov-08, <draft-patel-ecrit-sos-parameter-01.txt>
This memo describes requirements and protocol conventions for a new
SIP (Session Initiation Protocol) URI parameter intended for marking
SIP requests and responses related to emergency services. This
proposal addresses issues that exist in the current 3rd Generation
Partnership Project IP Multimedia Subsystem (IMS) Emergency services
solution, but is not precluded from being used by other SIP-based
emergency services solutions. It is not intended as a replacement
for the service URN.
"Delay-Tolerant Networking Metadata Extension Block", Susan Symington,
15-Sep-08, <draft-irtf-dtnrg-bundle-metadata-block-00.txt>
This document defines an extension block that may be used with the
Bundle Protocol [2] within the context of a Delay-Tolerant Network
architecture [4]. This Metadata Extension Block is designed to be
used to carry metadata that forwarding nodes can use to make routing
and other decisions regarding the bundle. This block is defined to
enable the actual metadata that is inserted into the block to have
any content and format, providing the format has been documented as a
metadata ontology. Specific metadata ontologies may be defined in
additional documents.
"IVI Update to SIIT and NAT-PT", Xing Li, Congxiao Bao, Fred Baker, Kevin
Yin, 16-Sep-08, <draft-baker-behave-ivi-01.txt>
This note proposes an address and service architecture designed to
facilitate transition from an IPv4 Internet to an IPv6 Internet.
This service contains three parts: A DNS Application Layer Gateway, a
stateful Network Address Translator that enables IPv6 clients to
initiate connections to IPv4 servers and peers, and a stateless
Network Address Translator that enables IPv4 and IPv6 systems to
interoperate freely.
It is couched as an update to RFCs 2765 and 2766. This is because
the stateless service is essentially the SIIT with a different
address format, and because the DNS Application Layer Gateway and the
stateful translator have significant similarities to NAT-PT. There
are, however, important differences from NAT-PT, responsive to the
issues raised in RFC 4966.
"BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya,
Frank Xia, 15-Sep-08, <draft-sarikaya-mext-bu-prefixdelegation-00.txt>
This document defines prefix delegation support for a mobile network.
Mobile Router dynamically requests its Mobile Network Prefixes from
its Home Agents using Binding Update both at the home link and at the
visited links. Home agents get the prefixes delegated using DHCPv6
Prefix Delegation and reply to the Mobile Router with Binding
Acknowledgement.
"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", James Randall, 15-Sep-08, <draft-randall-3447bis-00.txt>
This memo represents a republication of PKCS #1 v2.1 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document is taken directly from the PKCS #1 v2.1 document, with
certain corrections made during the publication process. This is an
update of 3447. Certain errors were also corrected for this update
and are identified in the text.
"A Comparison of Proposals to Replace NAT-PT", Dan Wing, David Ward, Alain
Durand, 29-Sep-08, <draft-wing-nat-pt-replacement-comparison-02.txt>
As we approach IPv4 address depletion, the IETF must provide for IPv4
and IPv6 coexistence: a way for ISPs and enterprises to reduce
public IPv4 address consumption and a way for hosts to migrate to
IPv6 connectivity -- while providing reasonable access for those IPv6
hosts to access the IPv4 Internet.
This draft compares eight proposals for IPv6 and IPv4 coexistence.
"Decrypted Content Attachment Flag for Internet Message Access Protocol
(IMAP)", Dan Newman, Ned Freed, 16-Sep-08, <draft-newman-imap-decaf-00.txt>
This document promulgates an Internet Message Access Protocol (IMAP)
flag keyword which Mail User Agents (MUAs) may use to indicate that
the decrypted content of an encrypted message contains one or more
attachments.
This document intentionally leaves undefined the definition of an
"attachment" and is neutral as regards the message encryption system.
This document also defines an IANA registry for IMAP flag keyword
conventions.
"Multicast Support Requirements for Proxy Mobile IPv6", Hui Deng, Thomas
Schmidt, Pierrick Seite, Peng Yang, 19-Oct-08,
<draft-deng-multimob-pmip6-requirement-01.txt>
This document summarizes requirements for multicast listener support
in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to
PMIPv6, multicast mobility management requirements do not request any
active participation of the mobile node.
"Wireless Multi-path Transmission Using SCTP", Hong-Ke Zhang, Bo Wang, Fei
Song, Huan Yan, 16-Sep-08, <draft-zhang-wcmt-sctp-00.txt>
In this draft, WCMT-SCTP(WCMT:Wireless Concurrent Multi-path
Transfer)is proposed to allow a host to improve the transmission
throughput in wireless multi-hop networks using simultaneous multi-
path transmission of Stream Control Transmission Protocol. Relevant issues
of WCMT-SCTP included are: (1) data transmission mode and path selection,
(2) path management and, (3) multi-path handover mechanism. Transmission
modes of WCMT-SCTP, and the path handover mechanism, are designed to enhance
the transmission throughput and solve the receive buffer blocking problem
of different wireless link status. Since the transmission paths used for
WCMT-SCTP may differ when an WCMT-SCTP host moves, the multi-path handover
problem is defined, and a handover mechanism is proposed.
"IPv6 Connectivity Check and Redirection by HTTP Servers", Eric Vyncke,
17-Sep-08, <draft-vyncke-http-server-64aware-00.txt>
Rather than forcing the client to decide whether IPv4 or IPv6 is more
convenient to reach a web server; this document proposes to let the
web server check whether there is IPv6 connectivity to the client;
then the web server can do a HTTP redirect to the force the client to
use IPv6.
This is done easily by a script within the server HTML pages and does
not require any change in the client applications or configuration.
The client still can control whether he/she wants to enabled IPv6.
This draft could be discussed on the Applications Discuss mailing
list, https://www.ietf.org/mailman/listinfo/apps-discuss.
"IETF Streaming Media, Current Status", Joel Jaeggli, 17-Sep-08,
<draft-jaeggli-ietf-streaming-media-status-00.txt>
This document describes the operation of the audio streaming service
provided for the IETF from IETF 62 up to the most recent (IETF 72)
meeting. Efforts associated with meetings prior to IETF 62 back to
IETF 49 as well as a proposal for the current effort were detailed in
the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of
this document is to inform future efforts to deliver streaming media
services for remote or local participants of the level of service and
the technology that was employed.
"Signaling 3 PCN states with baseline encoding", Ruediger Geib, 19-Sep-08,
<draft-geib-baseline-encoding-3state-00.txt>
Layer 2 transport services like MPLS offer only 2 states to encode
ECN state, if DiffServ based Class of Service is operated. Still, a
mechanism by which PCN egress nodes can differentiate between the
normal behaviour state, admission stop state control state and flow
termination state, by using PCN marking of packets is desirable.
This document describes how threshold and excess marking can be
combined with PCN baseline encoding. A minimalistic approach like
the one described in the following has some obvious shortcomings.
These shortcomings are also presented and discussed. Currently, the
aim of this document is to trigger experimentation feasability
studies. Standardisation will be pursued in the future based on the
results of the studies.
"IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Jari Arkko, Mark
Townsley, 19-Sep-08, <draft-arkko-townsley-coexistence-00.txt>
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.
"RTP Payload Format for MPEG-4 Audio/Visual Streams", Yoshihiro Kikuchi,
Yoshinori Matsui, Toshiyuki Nomura, Shigeru Fukunaga, Hideaki Kimata, Malte
Schmidt, Frans Bont, Intellectual Property, 19-Sep-08,
<draft-schmidt-avt-rfc3016bis-00.txt>
This document describes Real-Time Transport Protocol (RTP) payload
formats for carrying each of MPEG-4 Audio and MPEG-4 Visual
bitstreams without using MPEG-4 Systems. For the purpose of directly
mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides
specifications for the use of RTP header fields and also specifies
fragmentation rules. It also provides specifications for
Multipurpose Internet Mail Extensions (MIME) type registrations and
the use of Session Description Protocol (SDP).
Comments are solicited and should be addressed to the working group's
mailing list at avt@ietf.org and/or the author(s).
"Using POST to add Members to Web Distributed Authoring and Versioning
(WebDAV) Collections", Julian Reschke, 2-Oct-08,
<draft-reschke-webdav-post-01.txt>
The Hypertext Transfer Protocol (HTTP) Extensions for the Web
Distributed Authoring and Versioning (WebDAV) do not define the
behavior for the "POST" method when applied to collections, as the
base specification (HTTP) leaves implementers lots of freedom for the
semantics of "POST".
This has lead to a situation where many WebDAV servers do not
implement POST for collections at all, although it is well suited to
be used for the purpose of adding new members to a collection, where
the server remains in control of the newly assigned URL. As a matter
of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for
that purpose. On the other hand, WebDAV-based protocols such as the
Calendar Extensions to WebDAV (CalDAV) frequently require clients to
pick a unique URL, although the server could easily perform that
task.
This specification defines a discovery mechanism through which
servers can advertise support for POST requests with the
aforementioned "add collection member" semantics.
"Comparison of OSPF-MDR and OSPF-OR", Richard Ogier, Intellectual Property,
22-Sep-08, <draft-ogier-ospf-manet-mdr-or-comparison-00.txt>
This document presents a comparison of two proposed MANET extensions
of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison
and a qualitative comparison, which discusses the different design
choices and how they can affect performance and scalability.
"Comparison of OSPF-MDR and OSPF-MPR", Richard Ogier, Intellectual Property,
22-Sep-08, <draft-ogier-ospf-manet-mdr-mpr-comparison-00.txt>
This document presents a comparison of two proposed MANET extensions
of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative
comparison, which discusses the different design choices and how they
can affect performance and scalability, and a simulation comparison.
"RSVP-TE Recovery Signaling Fixes", Andrew Rhodes, Nic Neate, David McWalter,
24-Sep-08, <draft-rhodes-ccamp-rsvp-recovery-fix-00.txt>
This document updates the ASSOCIATION object used in RSVP-TE
signaling of End-to-End and Segment Recovery. This document solves
problems with existing Segment Recovery procedures, and also makes
possible recovery paths that cross addressing domain boundaries.
"Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen,
3-Nov-08, <draft-bajko-v6ops-port-restricted-ipaddr-assign-02.txt>
With the foreseen scarcity of public IPv4 addresses and the
hesitation and technical difficulties to deploy IPv6, the transition
scenarios which assumed that migration to IPv6 happens before the
run-out of IPv4 addresses, need to be revisited.
This document defines a method to allocate the same IPv4 address to
multiple hosts, thus prolonging the availability of public IPv4
addresses for as long as it takes for IPv6 to take over the demand
for IPv4. The document also describes the deployment scenarios where
this method is applicable.
"Alternative Approaches to Traffic Engineering Database Creation and
Maintenance for Path Computation Elements", Greg Bernstein, Young Lee, Dan
Li, 26-Sep-08, <draft-lee-pce-ted-alternatives-00.txt>
Path Computation Elements (PCEs) require an accurate and timely
Traffic Engineering Database (TED). Traditionally this TED has been
obtained from a link state routing protocol supporting traffic
engineering extensions. This document discusses possible alternatives
and enhancements to such an approach and their potential impacts on
network nodes, routing protocols, and PCEs.
"Fast Connectivity Restoration Using BGP Add-path", Pradosh Mohapatra, Rex
Fernando, Clarence Filsfils, Robert Raszuk, 27-Sep-08,
<draft-pmohapat-idr-fast-conn-restore-00.txt>
A BGP route defines an association of an address prefix with an "exit
point" from the current Autonomous System (AS). If the exit point
becomes unreachable due to a failure, the route becomes invalid.
This usually triggers an exchange of BGP control messages after which
a new BGP route for the given prefix is installed. However,
connectivity can be restored more quickly if the router maintains
precomputed BGP backup routes. It can then switch to a backup route
immediately upon learning that an exit point is unreachable, without
needing to wait for the BGP control messages exchange. This document
specifies the procedures to be used by BGP to maintain and distribute
the precomputed backup routes. Maintaining these additional routes
is also useful in promoting load balancing, performing maintenance
without causing traffic loss, and in reducing churn in the BGP
control plane.
"OAuth: HTTP Authorization Delegation Protocol", Eran Hammer-Lahav, Blaine
Cook, 29-Sep-08, <draft-hammer-oauth-00.txt>
This document specifies OAuth, an HTTP authorization delegation
protocol for accessing protected resources.
"Dual-stack lite broadband deployments post IPv4 exhaustion", Alain Durand,
Ralph Droms, Brian Haberman, James Woodyatt, 2-Nov-08,
<draft-durand-softwire-dual-stack-lite-01.txt>
The common thinking for more than 10 years has been that the
transition to IPv6 will be based on the dual stack model and that
most things would be converted this way before we ran out of IPv4.
It has not happened. The IANA free pool of IPv4 addresses will be
depleted soon, well before any significant IPv6 deployment will have
occurred.
This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6. Dual-stack lite will provide the necessary bridge
between the two protocols, offering an evolution path of the Internet
post IANA IPv4 depletion.
"A Profile for AS Adjacency Attestation Objects", Geoff Huston, George
Michaelson, 29-Sep-08, <draft-huston-sidr-aao-profile-00.txt>
This document defines a standard profile for AS Adjacency Attestation
Objects (AAOs). An AAO is a digitally signed object that provides a
means of verifying that an AS has made an attestation that it has a
inter-domain routing adjacency with one or more other AS's, with the
associated inference that this AS may announce or receive routes with
these adjacent AS's.
"Stateless Address Mappings (SAMs) IPv6 & extended IPv4 via local routing
domains - possibly multihomed", Remi Despres, 3-Nov-08,
<draft-despres-sam-01.txt>
Stateless Address Mapping (SAM) is a generic technique to achieve
global IPv4 or IPv6 connectivity across local domains where routing
is in a different address space. To cope with the IPv4 address
shortage, it supports an extension of IPv4 addresses with dynamic-
port prefixes. For multi-homed routing domains, it ensures that
source addresses that cross domain borders are always routable in the
reverse direction (Reverse Path Forwarding). SAM can be used alone
as an alternative to NATs, to improve scalability and end-to-end
network transparency, or in combination with NATs, to cover a wider
range of IPv4-IPv6 coexistence scenarios.
"Comprehensive DNS Resolver Defenses Against Cache Poisoning", Nicholas
Weaver, 30-Sep-08, <draft-weaver-dnsext-comprehensive-resolver-00.txt>
DNS resolvers are vulnerable to many attacks on their network
communication, ranging from blind attacks to full men-in-the-middle.
Although a full man-in-the-middle can only be countered with
cryptography, there are many layers of defenses which apply to less
powerful attackers. Of particular interest are defenses which only
require changing the DNS resolvers, not the authoritative servers or
the DNS protocols. This document begins with a taxonomy of attacker
capabilities and desires, and then discusses defenses against classes
of attackers, including detecting non-disruptive attacks, entropy
budgeting, detecting entropy stripping, semantics of duplication, and
cache policies to eliminate "race-until-win" conditions. Proposed
defenses were evaluated with traces of network behavior.
"Approach to Digital Signature Systems Deployment", John Marchioni, Yair
Itzhaki, 30-Sep-08, <draft-digital-signature-system-deployment-00.txt>
Conventional deployments store keys on PC hard disks, application-
server hard disks, or in tokens, and also introduce complications
for user enrollment and management. User and administrator
frustration with the conventional approach has cramped development
of a market for PKI. As a result, PKI has not reached its
utilization potential and is far from becoming ubiquitous.
This document describes architecture for deployment of secure and
efficient digital signature capabilities based on a centralized key-
management approach and emphasizes the importance of not disrupting
existing identity and authentication management and application
infrastructure. An alternative architecture is documented here so
that PKI deployments will lower their associated administrative
burdens and deliver improved scalability.
"MLD Source Address Selection for Mobile Multicast", Hong-Ke Zhang, Jian-feng
Guan, Hua-chun Zhou, Zhi-wei Yan, 30-Sep-08,
<draft-zhang-multimob-mldsas-mmcast-00.txt>
With the development of wireless and mobile technologies, mobile
multicast becomes a research hotspot. However, the current multicast
routing protocols can not provide the mobile multicast services. To
support the mobile multicast, the related multicast specifications
need to be extended. In this memo, we focus on the group membership
management protocol and define the new source address selection
policy for mobile multicast.
"The Extension in NetLMM to Carry Network Condition Information", Hong-Ke
Zhang, Hua-chun Zhou, Zhi-wei Yan, Jian-feng Guan, 30-Sep-08,
<draft-zhang-netlmm-pmipv6-extension-00.txt>
The NetLMM WG is specifying Proxy Mobile IPv6 for network-based
localized mobility management (NetLMM), taking basic support for
registration, de-registration and handover into account in the first
protocol release. When a mobile node connects to the access networks
through a sole interface or multiple interfaces, the condition of the
access networks should be considered to improve the performance of
the ongoing applications. According to the normal operation, Local
Mobility Anchor (LMA) can not get enough information to do the
necessary scheduling with Mobile Access Gateway (MAG) and Mobile Node
(MN), such as flow distribution. This document defines a PMIPv6 extension
that carries network condition in the form of simple class indication which
is calculated and sent from MAG to LMA in the Access Technology Type option.
"Router Advertisement Extension to Recognize Access Location for Mobile
Router", Hong-Ke Zhang, Zhi-wei Yan, Hua-chun Zhou, Jian-feng Guan,
30-Sep-08, <draft-zhang-mext-ramr-00.txt>
The Router Advertisement message in IPv6 Neighbor Discovery Protocol
[2] contains an 8-bit field reserved for single-bit flags. Several
protocols have reserved flags in this field and others are preparing
to reserve a sufficient number of flags to exhaust the field. This
document defines a flag to the Router Advertisement message that
extends the available number of flag bits available. The extended
flag defined in this document is mainly used by Mobile Router to
identify its location.
"Identity Handling at a Session Initiation Protocol (SIP) User Agent", John
Elwell, 1-Oct-08, <draft-elwell-sip-identity-handling-ua-00.txt>
Session Initiation Protocol (SIP) User Agents (UA) receive
identifiers for the caller and callee during call establishment.
These identifiers can come in a variety of forms, can be delivered by
a variety of means, and may or may not be accompanied by evidence of
authenticity. Furthermore, if media are secured (e.g., using the
Secure Real-Time Protocol, SRTP), the security properties of the
media will depend on binding the media to a received authenticated
identifier. This document examines the various identification
information a UA can receive during call establishment and how a user
agent can use this information to present a caller or callee
identifier to the user and indicate to the user the security
properties of the call, as well as how the user agent might use this
information for other purposes, such as authorizing acceptance of a
call.
This work is being discussed on the sip@ietf.org mailing list.
"IKEv2 Session Resumption", Yaron Sheffer, Hannes Tschofenig, Lakshminath
Dondeti, Vidya Narayanan, 3-Nov-08,
<draft-tschofenig-ipsecme-ikev2-resumption-01.txt>
The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips
and consequently latency.
To re-establish security associations (SA) upon a failure recovery
condition is time consuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.
The proposed approach uses a ticket to store state information that
is later made available to the IKEv2 responder for re-authentication.
Restoring state information by utilizing a ticket is one possible
way. This document does not specify the format of the ticket but
recommendations are provided.
"RFC Editor Model", Olaf Kolkman, 3-Nov-08,
<draft-iab-rfc-editor-model-02.txt>
The RFC Editor performs a number of functions that may be carried out
by various persons or entities. The RFC Editor model presented in
this document divides the responsibilities for the RFC Series into
four functions: The RFC Series Editor, the Independent Submission
Editor, RFC Production Center, and the RFC Publisher. The model
outlined here is intended to increase flexibility and operational
support options, provide for the orderly succession of the RFC
Editor, and ensure the continuity of the RFC series, while
maintaining RFC quality, maintaining timely processing, ensuring
document accessibility, reducing costs, and increasing cost
transparency.
"Clearance Sponsor Attribute", Sean Turner, 3-Oct-08,
<draft-turner-clearancesponsor-attribute-00.txt>
This document defines the clearance sponsor attribute. This
attribute may be carried in a public key certificate in the Subject
Directory Attributes extension, in an attribute certificate in the
attribute field, in a directory as an attribute, or in protocols that
support attributes.
"Device Owner Attribute", Sean Turner, 3-Oct-08,
<draft-turner-deviceowner-attribute-00.txt>
This document defines the deviceOwner attribute. This attribute may
be carried in a public key certificate in the Subject Directory
Attributes extension, in an attribute certificate in the attribute
field, in a directory as an attribute, or in protocols that support
attributes.
"Threat Model for Networks Employing AAA Proxies", Stefan Winter, Katrin
Hoeper, 3-Nov-08, <draft-hoeper-proxythreat-01.txt>
This memo defines a threat model for access networks with AAA
proxies. Use cases of current and future applications in which AAA
proxies are employed are described and it is discussed how proxies
could launch attacks in the defined use cases. The risk associated
with these attacks in each use case is analyzed. As a result, this
draft can serve as a guideline for risk assessments by providers,
implementers and protocol designers of systems with proxies.
"IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", Ed Guy,
5-Oct-08, <draft-guy-iaxiana-00.txt>
This document establishes the IANA registries for IAX, the Inter-
Asterisk eXchange protocol, an application-layer control and media
protocol for creating, modifying, and terminating multimedia sessions
over Internet Protocol (IP) networks. IAX was developed by the open
source community for the Asterisk PBX and is targeted primarily at
Voice over Internet Protocol (VoIP) call control, but it can be used
with streaming video or any other type of multimedia.
"RPKI Repository Retrieval Mechanism", Terry Manderson, George Michaelson,
5-Oct-08, <draft-manderson-sidr-fetch-00.txt>
This document proposes a mechanism for a relying party to synchronise
a local cache of the RPKI repository using a HTTPS retrieval
mechanism.
"A UDP/IP Adaptation of the ZigBee Application Protocol", Gilman Tolle,
8-Oct-08, <draft-tolle-cap-00.txt>
This document describes a UDP/IP adaptation of the IEEE 802.15.4-
based ZigBee Application Protocol that enables IP hosts to
communicate using the application profiles and data models described
by that protocol, over a wide range of links. This modified version
of the ZigBee Application Protocol is named CAP (Compact Application
Protocol), and it is intended to provide a complete stack of
application profiles, data exchange, binding operations, security
protocols, and discovery to IP-networked hosts and embedded devices.
The protocol's domain of applicability includes IEEE 802.15.4-based
6LoWPAN devices, but also those on conventional wired and wireless
links and emerging powerline communication networks.
"Revised Default Values for the BGP 'Minimum Route Advertisement Interval'",
Paul Jakma, 17-Nov-08, <draft-jakma-mrai-02.txt>
This document briefly examines what is known about the effects of the
BGP MRAI timer, particularly on convergence. It highlights published
work which suggests the MRAI interval as deployed has an adverse
effect on the convergence time of BGP.
It then recommends revised, lower default values for the MRAI timer,
thought to be more suited to today's Internet environment.
"Load Sharing in Proxy Mobile IPv6", An-fu Zhou, Gang Chen, Min Liu, Dapeng
Liu, 9-Oct-08, <draft-zhou-netlmm-pmipv6-load-sharing-00.txt>
Proxy Mobile IPv6 is a network-based mobility management protocol.
The mobility entities involved in the Proxy Mobile IPv6 protocol, the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA),
setup tunnels dynamically to manage mobility for a mobile node within the
Proxy Mobile IPv6 domain. This document proposes to use multiple LMAs for
the consideration of traffic overload, and describes a load sharing mechanism
between multiple LMAs.
"LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli,
10-Oct-08, <draft-korhonen-netlmm-lma-discovery-00.txt>
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 specification describes a number of
possible dynamic Local Mobility Anchor discovery solutions.
"IMAP Annotation for Indicating Message Authentication Status", Murray
Kucherawy, 10-Oct-08, <draft-kucherawy-sender-auth-imap-00.txt>
This memo defines an application of the IMAP (Internet Message Access
Protocol) Annotations facility whereby a server can store and
retrieve meta-data about a message relating to message authentication
tests performed on the message and the corresponding results.
"Operating MPLS Transport Profile LSP in Loopback Mode", Sami Boutros, Siva
Sivabalan, David Ward, George Swallow, 10-Oct-08,
<draft-boutros-mpls-tp-loopback-00.txt>
This document specifies an extension to MPLS Operation,
Administration, and Maintenance (OAM) using which an MPLS Label
Switching Router (LSR) can explicitly request another MPLS LSR to
operate an MPLS Transport Profile(MPLS-TP) Label Switched Path
between the two LSRs in loopback mode. This extension can be used to
loop the data traffic up to certain LSR in the path of the MPLS LSP
back to the source for management purpose.
"PREFIX64 Comparison", Hiroshi Miyata, 13-Oct-08,
<draft-miyata-behave-prefix64-00.txt>
There are several NAT64 and/or NAT46 proposals. Each of them have
recommended PREFIX64, which is used to represent IPv4 address in IPv6
address format. Each of them have advantages and shortcomes.
Therefore the preferable PREFIX64 would depends on the utilization
scene. This draft compares seven proposals for IPv6 and IPv4
coexistence.i
"Diameter Command Codes for 3GPP EPS Diameter Applications", Mark Jones,
Lionel Morand, 14-Oct-08, <draft-jones-3gpp-eps-command-codes-00.txt>
This document describes a set of new IANA Diameter Command Codes to
be used in new vendor-specific Diameter applications defined for the
Third Generation Partnership Project (3GPP) Evolved Packet System
(EPS).
"Routing and Addressing in Next-Generation EnteRprises (RANGER)", Fred
Templin, 17-Nov-08, <draft-templin-ranger-04.txt>
Enterprise networks will require support for both Internet protocol
versions (IPv4 and IPv6) for an indeterminant period; perhaps even
indefinitely. This is particularly true for existing enterprise
networks that must introduce IPv6 without disruption of IPv4
services, but the same principles apply even for clean-slate
deployments in new enterprises. Next-generation enterprises
therefore require an architected solution for coordination of their
internal routing and addressing plans for both IPv6 and IPv4. The
RANGER architecture addresses these requirements.
"CAPWAP WLAN-VLAN Information Message Element", Haibo Wen, Sudhanshu JAIN,
14-Oct-08, <draft-wen-capwap-wlan-vlan-00.txt>
In Control And Provisioning of Wireless Access Points Protocol, the
WLANs on the Wireless Termination Point are created by the Access
Controller with the appropriate setting. This document defines a mew
messages elements, i.e., WLAN-VLAN Information message element, which
is used to set WLAN-VLAN binding information on the WTP.
"CAPWAP Station IP Address", Haibo Wen, Sudhanshu JAIN, 14-Oct-08,
<draft-wen-capwap-station-ip-address-00.txt>
In Control And Provisioning of Wireless Access Points Protocol, the
Access Controller controls whether Wireless Termination Point should
forward the traffic for some specified station. This document defines
a mew messages elements, IEEE Station IP Address, which are used for
better control of station's access in local-MAC mode of CAPWAP.
"Intradomain Presence and IM Federation Call Flow Examples", Sanjay Sinha,
Avshalom Houri, 14-Oct-08,
<draft-sinha-simple-intradomain-federation-callflow-00.txt>
This document gives call flow examples and relevant message details
at the interface of two federating server that have implemented
intradomain federation using the model described in Models for Intra-
Domain Presence and Instant Messaging (IM) Federation,
[I-D.ietf-simple-intradomain-federation].
"Feature Interactions Problem Statement", Rui Gustavo Crespo, Luigi Logrippo,
14-Oct-08, <draft-cl-sipping-fi-problem-00.txt>
Internet applications have been enhanced with many features.
A feature may be defined as a unit of functionality in a system, having
a self-contained role.
However, the introduction and modification of features may result in
undesired behaviors, and this effect is known as feature interaction-
FI for short.
This document provides a description of the FI problem in Internet, the
main problems to be solved in the FI resolution, and compares some
solutions for FI identification and resolution explored that have been
discussed in the literature.
"Distributed Resolution of Feature Interactions for Internet Applications",
Rui Gustavo Crespo, Luigi Logrippo, 15-Oct-08,
<draft-cl-sipping-fi-resolution-00.txt>
Internet applications have been enhanced with many features.
A feature may be defined as a unit of functionality in a system, having
a self-contained role.
However, the introduction and modification of features may result in
undesired behaviors, and this effect is known as feature interaction -
FI for short.
This document specifies the architecture of a distributed feature mana-
ger that proposes the resolution of feature interactions. The resolu-
tion may be done locally, or with cooperation between different nodes.
The resolution method is left to the implementation. In this document we
provide an example of one resolution method, based on feature interdiction,
as described by a set of deontic formulas.
"draft-nottingham-site-meta-00", Mark Nottingham, Eran Hammer-Lahav,
15-Oct-08, <draft-nottingham-site-meta-00.txt>
This memo describes a method for locating site-wide metadata for Web
sites.
"RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1)
Protocol Support", Glen Zorn, 17-Oct-08, <draft-zorn-radius-pkmv1-01.txt>
This document defines a set of RADIUS Attributes which are designed
to provide RADIUS support for IEEE 802.16 Privacy Key Management
Version 1.
"Use of IP Router Alert Considered Dangerous", Reshad Rahman, David Ward,
17-Oct-08, <draft-rahman-rtg-router-alert-dangerous-00.txt>
This document provides guidelines to address security concerns which
arise with the use of IP Router Alert option [RFC2113] and [RFC2711].
RSVP,[RFC2205] and [RFC3209], and IGMP [RFC3376] are some of the
protocols which make use of the IP Router Alert option. IP datagrams
carrying the Router Alert option are usually examined in a router's
"slow path" and an excess of such datagrams can cause performance
degradation or packet drops in a router's "slow path".
"IPv6 destination header option for IPv4 translator mapping notification",
Remi Denis-Courmont, 20-Oct-08, <draft-denis-behave-v4v6exthdr-00.txt>
This memo defines a new IPv6 Destination header option to convey the
transport mapping information from an IPv4-IPv4 protocol translator
to the IPv6 end of a protocol-translated packet flow.
"IPv6 Ephemeral Addresses", Hiroshi Kitamura, Shingo Ata, Masayuki Murata,
20-Oct-08, <draft-kitamura-ipv6-ephemeral-address-00.txt>
This document describes a new address type that is called
"Ephemeral Addresses". Ephemeral Addresses are designed to be used
as clients' source addresses of TCP / UDP sessions. An idea
Ephemeral Addresses is simple enough. They are achieved by deriving
existing "ephemeral ports" specifications. In other words, they are
achieved by naturally upgrading their concept from the port space
to the address space. Since Ephemeral Addresses functions are
implemented only in the kernel side of the OS, we can use the
Ephemeral Addresses functions in current exiting enormous client
applications without modifying them. Ephemeral Addresses functions
can contribute to various types of security enhancements that
include privacy protections etc.
"EAI Deployment Practices", Jiankang Yao, XiaoDong Lee, Xiaodong WU,
20-Oct-08, <draft-yao-eai-deployment-00.txt>
This document captures experience in implementing systems based on
the EAI protocols. Its aim is to help the engineers to implement
these protocols. This document gives some suggestions about
implementaions and reports on the prototype implementation and the
inter-operability test results, as well as the lessons and insights
gained from this test.
"Extension of Multiple Care-of Addresses Registration for Handover", Hong-Ke
Zhang, Zhi-wei Yan, Hua-chun Zhou, Jian-feng Guan, 20-Oct-08,
<draft-zhang-mext-mcoa-extension-00.txt>
The Multiple Care-of Addresses Registration [2] is a useful protocol
which allows a mobile node to get Internet access through multiple
accesses simultaneously, in which case the mobile node would be
configured with multiple active IPv6 care-of addresses. It proposes
extensions to the Mobile IPv6 protocol to register and use multiple
care-of addresses with the Binding Identifier Mobility Option. This
document describes a simple extension to Binding Identifier Mobility
Option to allow mobile node to select the most wanted link for the
ongoing service.
"Asymmetric Key Packages", Sean Turner, 30-Oct-08,
<draft-turner-asymmetrickeyformat-01.txt>
This document defines the syntax for private key information and a
content type for it. Private-key information includes a private key
for some public-key algorithm and a set of attributes. The document
also describes a syntax for encrypted private keys. The
Cryptographic Message Syntax, as defined in RFC 3852, can be used to digitally
sign, digest, authenticate, or encrypt the asymmetric key format content
type. This document obsoletes RFC 5208.
"Delivering Geographic Location in Host Identity Protocol (HIP)", Feng Cao,
David Ward, Hui Deng, 27-Oct-08, <draft-cao-hip-geolocation-01.txt>
This document defines a new parameter for delivering geographic
location in Host Identity Protocol (HIP). For mobile users using
HIP, one generic mechanism is proposed to share or update their geo-
location information with either rendezvous servers or their peers.
In addition, geo-location privacy is also protected with the help of
the ENCRYPTED parameter.
"RADIUS Support for Prefix Authorization", Behcet Sarikaya, Frank Xia,
2-Nov-08, <draft-sarikaya-radext-prefix-authorization-01.txt>
This document specifies new attributes for supporting prefix
authorization. Using RADIUS protocol, a client requests prefixes
from a server; the client gives back the prefixes to the server; the
client is responsible for renewing the prefixes when the lifetime
expires. The RADIUS server can also renumber prefixes. RADIUS
clients can be home agents in MIPv6 and NEMO scenario, local mobile
anchors in Proxy MIPv6 scenario, or common access routers.
"Using mLDP through a Backbone where there is no Route to the Root", IJsbrand
Wijnands, Eric Rosen, Maria Napierala, 21-Oct-08,
<draft-wijnands-mpls-mldp-csc-00.txt>
The control protocol used for constructing Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a
field that identifies the address of a "root node". Intermediate
nodes are expected to be able to look up that address in their
routing tables. However, if the route to the root node is a BGP
route, and the intermediate nodes are part of a BGP-free core, this
is not possible. This document specifies procedures which enable a
MP LSP to be constructed through a BGP-free core. In these
procedures, the root node address is temporarily replaced by an
address which is known to the intermediate nodes.
"RTP Payload Format for Bluetooth's SBC audio codec", Christian Hoene, Frans
de Bont, 21-Oct-08, <draft-hoene-avt-rtp-sbc-00.txt>
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the low complexity subband codec (SBC), which
is the mandatory audio codec of the Advanced Audio Distribution
Profile (A2DP) Specification written by the Bluetooth(r) Special Interest
Group (SIG). The payload format is designed to be able to interoperate with
existing Bluetooth A2DP devices, to provide high streaming audio quality,
interactive audio transmission over the internet, and ultra-low delay coding
for jam sessions on the internet. This document contains also a media type
registration which specifies the use of the RTP payload format.
"Generic Subtype for BGP Four-octet AS specific extended community",
Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 21-Oct-08,
<draft-dhrao-idr-4octet-extcomm-generic-subtype-00.txt>
Maintaining the current best practices with communities, ISPs and
enterprises that get assigned a 4-octet AS number may want the BGP
UPDATE messages they receive from their customers or peers to include
a 4-octet AS specific extended community. This document defines a
new sub-type within the four-octet AS specific extended community to
facilitate this practice.
"IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", Jari
Arkko, 24-Oct-08, <draft-arkko-arp-iana-rules-01.txt>
This document specifies the IANA guidelines for allocating new values
in the Address Resolution Protocol (ARP). This document also
reserves some numbers for experimentation purposes.
"ALTO: A Multi Dimensional Peer Selection Problem", Saumitra Das, Vidya
Narayanan, Lakshminath Dondeti, 22-Oct-08,
<draft-saumitra-alto-multi-ps-00.txt>
Bulk data applications are posing serious challenges to the Internet
infrastructure and more mass adoption of such applications would only
increase that challenge. P2P bulk data applications and other large
volume HTTP traffic such as video currently dominate the Internet
traffic. These applications do not generally benefit from the
traffic engineering techniques developed for the Internet. In the
HTTP traffic case, the traffic optimization issues are often
addressed using the CDN infrastructure. For P2P bulk data
applications, the problem is about picking the right peers to
communicate with and the criteria for doing this vary greatly based
on the application. Hence, intelligent peer selection is the
fundamental problem to address for these applications. This document
explains the multiple dimensions of the peer selection problem with
respect to obtaining information from the network as well from other
peers and argues for an integrated, common framework to share such
information.
"Requirements for the Support of Continuously Varying Values in Presence",
Martin Thomson, 22-Oct-08,
<draft-thomson-simple-cont-presence-val-req-00.txt>
The attributes of continuous-valued data are examined in respect to
presence systems. The limitations of the existing presence system
with respect to continuous-valued data is examined. Requirements are
formulated that would enable the use of the presence system for this
data, with an emphasis on providing the watcher with a means of
control over the measurement process.
"Provider-Provisioned CPE: IPv4 Connectivity Access in the context of IPv4
address exhaustion", Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis,
Alain Villefranque, 23-Oct-08, <draft-boucadair-port-range-00.txt>
This memo proposes a solution, based on fractional addresses, to face
the IPv4 public address exhaustion. It details the solution and
presents a mock-up implementation, with the results of tests that
validate the concept. Finally, it makes a comparison with the
alternative Carrier-Grade NAT (CG-NAT) solutions.
"IPv6 Inverse Neighbor Discovery Update", Pascal Thubert, Eric Levy-Abegnoli,
23-Oct-08, <draft-thubert-3122bis-00.txt>
This draft updates the Inverse Discovery Specification [RFC3122] to
provide Secure Neighbor Discovery. The behaviour of the protocol is
slightly amended to enable an easier management of the addresses on a
link and enable Secure ND.
"PANA (Protocol for Carrying Authentication for Network Access) Base Protocol
MIB", Victor Fajardo, 23-Oct-08, <draft-fajardo-pana-pana-mib-00.txt>
This document defines the Management Information Base (MIB) module
which defines a minimum set of objects that can be used to manage an
implementation of the PANA Base Protocol [RFC5191].
"Renumbering still needs work", Brian Carpenter, Randall Atkinson, 23-Oct-08,
<draft-carpenter-renum-needs-work-00.txt>
This document reviews the existing mechanisms for site renumbering
for both IPv4 and IPv6, and identifies operational issues with those
mechanisms. It also summarises current technical proposals for
additional mechanisms. Finally there is a gap analysis.
"Domain name based network interface selection", Teemu Savolainen, 23-Oct-08,
<draft-savolainen-6man-fqdn-based-if-selection-00.txt>
A multi-homed host with multiple physical and/or virtual network
interfaces has to select which one of the network interfaces to use
for a new outgoing IPv4 or IPv6 connection. This document describes a
method to select an interface by using destination's fully qualified
domain name and DNS suffix information received dynamically for each
network interface. The method is useful, for example, in split
horizon DNS and walled garden scenarios, where right network
interface has to be selected even before DNS resolution is conducted.
"A Proposal to Define Interactive Connectivity Establishment for the
Transport Control Protocol (ICE-TCP) as an Extensible Framework", Adam Roach,
Bruce Lowekamp, 23-Oct-08, <draft-lowekamp-mmusic-ice-tcp-framework-00.txt>
The ICE-TCP mechanism is currently regarded as of limited usefulness
due to the low success rate of TCP simultaneous open for NAT
traversal. This document presents a vision of the ICE-TCP document
as an extensible framework for negotiating a variety of approaches
for establishing a TCP connection between NATed hosts. This document
further proposes significantly extending the current set of
collection mechanisms to encompass a wide variety of technologies
that are currently available, including UPnP, SOCKS, and Teredo.
Because several of these technologies are already widely deployed,
the direct connection rate should be significantly higher than using
straight TCP alone. We envision that as future TCP connection
establishment techniques are developed, they too will specify an ICE
encoding that will allow their negotiation.
"Local Mobile Anchor Discovery Using DHCP", Frank Xia, Behcet Sarikaya,
23-Oct-08, <draft-xia-netlmm-lma-discovery-00.txt>
This draft defines a DHCP-based scheme to enable dynamic discovery of
a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic
Host Configuration Protocol (DHCP) options are used allowing a Mobile
Access Gateway (MAG) to request the LMA's IP address, Fully Qualified
Domain Name (FQDN), or home network prefix via the DHCP response.
"Differentiation Using Virtualization of Mobile Network", Chulhyun Park,
Nakjung Choi, Taekyoung Kwon, Yanghee Choi, Eun Paik, 24-Oct-08,
<draft-mext-park-vnemo-00.txt>
A mobile router with multiple interfaces can make connection to
several access networks. Using virtualization on the mobile network,
several virtual mobile network can be exist for a single mobile
network. Multiple virtual mobile networks for a single mobile
network can be used for service differentiation for mobile network
nodes.
"Call Parameter Negotiation with GMPLS Calls", Hongmiao Xia, Jianhua Gao,
Fatai Zhang, 24-Oct-08, <draft-xia-ccamp-gmpls-call-application-00.txt>
This document defines the use of Generalized Multi-Protocol Label
Switching (GMPLS) Calls for parameter negotiation in Automatically
Switched Optical Networks (ASON) and Wavelength Switched Optical
Networks (WSON). The intention of the document is to provide a
reference for the authors of future documents to understand the
application of GMPLS Calls.
"CGA Extension Header of IPv6", Lifeng Liu, Dong Zhang, 24-Oct-08,
<draft-dong-savi-cga-header-00.txt>
This document specifies a method based on Cryptographically Generated
Addresses (CGA) for protecting the IPv6 network from address
spoofing. The basic idea is to define a new IPv6 extension header
which is called CGA header. Three new options of CGA header are
introduced to satisfy the need of verification between all CGA-aware
nodes. This document also illustrates the proposed verification
procedure under several different situations.
"RTP Payload format for GSM-HR", Magnus Westerlund, Karl Hellwig, Ingemar
Johansson, 24-Oct-08, <draft-westerlund-avt-rtp-gsm-hr-00.txt>
This document specifies the RTP payload format for packetization of
the GSM Half-Rate speech codec.
"Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui,
Samita Chakrabarti, Erik Nordmark, 17-Nov-08,
<draft-shelby-6lowpan-nd-01.txt>
This document specifies Neighbor Discovery optimized for 6LoWPAN.
The 6LoWPAN format allows IPv6 to be used over very low-power, low-
bandwidth wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery
over 6LoWPAN networks has several problems. Standard Neighbor
Discovery was not designed for wireless links, the standard IPv6 link
concept and heavy use of multicast makes it inefficient. This
document spefies a new mechanism allowing efficient Duplicate Address
Detection over entire 6LoWPAN networks. In addition it specifies
prefix and context dissemination for use with router advertisements,
allows for stateless address assignment, and the use of Neighbor
Discovery Proxy.
"Framework and Requirements for Composite Transport Group (CTG)", So Ning,
Andrew Malis, Dave McDysan, Lucy Yong, 24-Oct-08,
<draft-so-yong-mpls-ctg-framework-requirement-00.txt>
This document states a traffic distribution problem in today's IP/
MPLS network when multiple links are configured between two routers.
The document presents a Composite Transport Group framework as the
solution for the problems and specifies a set of requirements for
Composite Transport Group(CTG).
"Learning the Address Family Translator's IPv6 Prefix", Dan Wing, 24-Oct-08,
<draft-wing-behave-learn-prefix-00.txt>
In some IPv6/IPv4 translation scenarios it is necessary for an IPv6
host to know the IPv6 prefix used by its address family translator.
In some of the IPv6/IPv4 translation proposals, the prefix is not
fixed; that is, the prefix is chosen by the network operator. This
specification provides several methods to learn the prefix and its
length.
"MIKEY General Extension Payload for OMA BCAST 1.0", Anja Jerichow, Laurent
Piron, 24-Oct-08, <draft-jerichow-msec-mikey-genext-oma-00.txt>
This document extends the General Extension Payload for OMA BCAST
usage defined in RFC 4909 [1]. It adds necessary support for the
newly specified management data as defined in the Open Mobile
Alliance's (OMA) Broadcast (BCAST) group's Service and Content
protection specification [2].
"HTTP Access to Email Stores", Lisa Dusseault, 24-Oct-08,
<draft-dusseault-httpmail-00.txt>
This document proposes a standard format and a standard navigation
mechanism so that mail stores can provide interoperable access to
mailboxes and messages over HTTP. Mailbox contents and listings of
mailboxes are exposed as Atom Feeds, while messages themselves are
downloaded as a document of type message/822. Each mailbox and each
message is assigned an HTTP URL, and if permissions checks are
satisfied, each message may be downloaded independently.
"Flow Handover for Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury,
24-Oct-08, <draft-koodli-flow-handover-00.txt>
With interface multihoming, Mobile Nodes are capable of simultaneous
attachment to multiple radio access networks. This enables a network
node such as the Local Mobility Anchor to distribute the application
traffic to interfaces that can best serve them. This document
specifies a network-controlled protocol to handover application flows
from one interface to another. Such control could provide better
experience for end users and better traffic management for network
operators.
"Report from the IETF workshop on P2P Infrastructure, May 28, 2008", Jon
Peterson, Alissa Cooper, 24-Oct-08,
<draft-p2pi-cooper-workshop-report-00.txt>
This document reports the outcome of a workshop organized by the
Real-time Applications and Infrastructure Area Directors of the IETF
to discuss network delay and congestion issues resulting from
increased P2P traffic volumes. The workshop was held on May 28, 2008
at MIT in Cambridge, MA, USA. The goals of the workshop were
twofold: to understand the technical problems ISPs and end users are
experiencing as a result of high volumes of P2P traffic, and to begin
to understand how the IETF may be helpful in addressing these
problems. Gaining an understanding of where in the IETF this work
might be pursued and how to extract out feasible work items were
highlighted as important tasks in pursuit of the latter goal. The
workshop was very well attended and produced several work items that
have since been taken up by members of the IETF community.
"Fast Handover for IP Flow Mobility", Fan Zhao, Ameya Damle, 24-Oct-08,
<draft-zhao-mipshop-fho-flows-00.txt>
This document discusses and proposes some extensions to reduce
handover latency, especially when the mobile node or router handovers
IP flows between different access networks.
"Interworking between FMIP and PFMIP", Fan Zhao, Ameya Damle, 24-Oct-08,
<draft-zhao-mipshop-fmip-pfmip-00.txt>
This document discusses and proposes extensions to enable
interworking between the FMIP and the PFMIP.
"RTP Payload Format for Raptor FEC", Mark Watson, 24-Oct-08,
<draft-watson-fecframe-rtp-raptor-00.txt>
This document specifies an RTP Payload Format for Forward Error
Correction repair data produced by the Raptor FEC Schemes. Raptor
FEC Schemes are specified for use with the IETF FEC Framework which
supports transport of repair data over both UDP and RTP. This
document specifies the Payload Format which is required for the use
of RTP to carry Raptor repair flows.
"MPLS Tunnel Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya,
25-Oct-08, <draft-xia-netlmm-mpls-tunnel-00.txt>
The Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
(MAG) to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation
headers. In this document, Multiprotocol Label Switching (MPLS)
tunneling is proposed as an alternative tunnel technology which is
used between a MAG and a LMA. MPLS is now become more and more
popular, and MPLS support is an important function for edge and core
routers. Integrating MPLS and Proxy IP Mobility can leverage Proxy
IP Mobility deployment in the industry.
"An extension to RELOAD to support Direct Response and Relay Peer routing",
XingFeng Jiang, Roni Even, 25-Oct-08, <draft-jiang-p2psip-relay-00.txt>
This document proposes an extension to RELOAD to support direct
response and relay peer routing modes. The document starts with the
problem statement and address concerns about these two routing modes
mentioned in RELOAD. Then methods about how to discover NAT behavior
of the client in P2PSIP situations are discussed. The last part
proposes extensions to RELOAD for supporting these additional routing
modes.
"Mobile IPv6 Handover Using Home Agent Buffering", Frank Xia, Behcet
Sarikaya, Basavaraj Patil, 1-Nov-08, <draft-xia-mipshop-ha-buffering-01.txt>
In Mobile IPv6, when a Mobile Node (MN) moves from one Access
Router(AR) to another, there is a period during which the MN is
unable to send or receive packets because of link switching delay and
IP protocol operations. This document specifies a mechanism to
reduce packet loss through a Home Agent (HA) buffering downlink
packets during the handover period.
"DHCPv6 Remote Boot Options", Vincent Zimmer, Dave Thaler, 3-Nov-08,
<draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt>
This document describes a means by which to support network boot of a
bare-metal platform utilizing a pre-boot execution environment, such
as the Unified Extensible Firmware Interface [UEFI22]. The problem
being addressed is that the PXE [PXE21] and UEFI Specifications
[UEFI22] only describe how to ascertain boot configuration options
using DHCPv4 [RFC2131], not for DHCPv6 [RFC3315]. Similarly, iSCSI
boot [RFC4173] does not specify how to discover boot device
information in an DHCPv6 environment. This document will describe how
to ascertain this boot information in an IPv6 environment utilizing options
in the DHCPv6 hand-off [RFC3315].
"Measuring IP Performance Metrics on Mobile Network", Pyung-Soo Kim,
Sun-Young Shin, 26-Oct-08, <draft-pskim-ippm-nemo-measurement-00.txt>
In this draft, the new measurement scheme of IP performance metrics
is proposed for the mobile network in heterogeneous wireless network
environment. In the proposed scheme, all mobile nodes (MNs) inside
the mobile network can get IP performance metrics irrespective of
the presence or absence of measurement functionality. That is, the
proposed scheme does not require the MN to be involved in measuring
IP performance metrics. The multihomed mobile router (MR) with
heterogeneous wireless interfaces measures IP performance metrics
on behalf of the MNs inside the mobile network. Then, when MNs want
to understand the condition of multiple communication paths, MNs can
get measured IP performance metrics from the MR using L3 messages.
The proposed scheme can reduce burden and power consumption of MNs
with limited resource and battery power since MNs don't measure
directly IP performance metrics. In addition, the proposed scheme
can reduce considerably traffic overhead over wireless links on
measurement paths since signaling messages and injected testing
traffic are reduced.
"Framework for IPv4/IPv6 Translation", Fred Baker, 26-Oct-08,
<draft-baker-behave-v4v6-framework-00.txt>
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.
"IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
26-Oct-08, <draft-baker-behave-v4v6-translation-00.txt>
This document specifies an update to the Stateless IP/ICMP
Translation Algorithm (SIIT) described in RFC 2765. The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP
headers).
This specification addresses both a stateful and a stateless mode.
In the stateful mode, translation state is maintained between IPv4
address/transport/port tuples and IPv6 address/transport/port tuples,
enabling IPv6 systems to open sessions with IPv4 systems. In the
stateless mode, translation information is carried in the address
itself, permitting both IPv4->IPv6 and IPv6->IPv4 session
establishment with neither state nor configuration in the translator.
The choice of operational mode is made by the operator deploying the
network and is critical to the operation of the applications using
it.
Significant issues exist in the stateful mode that are not addressed
in this document, related to the maintenance of the translation
tables. This document confines itself to the actual translation.
Acknowledgement of previous work
This document is a product of the 2008-2009 effort to define a
replacement for NAT-PT. It is an update to and directly derivative
from Erik Nordmark's [RFC2765], which similarly provides both
stateless and stateful translation between IPv4 [RFC0791] and IPv6
[RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The
original document was a product of the NGTRANS working group. Some
text had been extracted from an old Internet Draft titled "IPAE: The
SIPP Interoperability and Transition Mechanism" authored by R.
Gilligan, E. Nordmark, and B. Hinden.
The changes in this document reflect five components:
1. Updating references
2. Redescribing the network model to map to present and projected
usage
3. Moving the address format to the framework document, to
coordinate with other drafts on the topic
4. Some changes in ICMP.
5. Description of both stateful and stateless operation.
"SeND-based Source-Address Validation Implementation", Marcelo Bagnulo,
26-Oct-08, <draft-bagnulo-savi-send-00.txt>
This memo describes SeND SAVI, a mechanism to provide source address
validation using the SeND protocol. The proposed mechanism is
intended to complement ingress filtering techniques to provide a
higher granularity on the control of the source addresses used.
"LDAP schema for storing SCRAM secrets", Alexey Melnikov, 19-Nov-08,
<draft-melnikov-sasl-scram-ldap-01.txt>
This memo describes how authPassword LDAP attribute can be used for
storing secrets used by Salted Challenge Response (SCRAM) Simple
Authentication and Security Layer (SASL) Mechanism.
Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
ietf-sasl@imc.org.
"DTN Bundle Metadata Confidentiality Specification", Peter Lovell, 26-Oct-08,
<draft-irtf-dtnrg-bundle-metadata-conf-00.txt>
This document describes a confidentiality ciphersuite for metadata in
Delay-Tolerant Networking (DTN) Bundle Protocol (BP) bundles.
"DTN EID References Specification", Peter Lovell, 26-Oct-08,
<draft-irtf-dtnrg-bundle-eidrefs-00.txt>
This document describes a convention for storing references to Delay-
Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers
[EIDs] within extension blocks of bundles.
"A Framework for defining Optical Parameters to be used in WSON networks
through GMPLS", Giovanni Martinelli, David Bianchi, Alberto Tanzi, Ori
Gerstel, Andrea Zanardi, 26-Oct-08,
<draft-martinelli-ccamp-opt-imp-fwk-00.txt>
In the context of Wavelength Switched Optical Networks (WSON) the
problem of selecting a lightpath might be constrained by an
evaluation of the optical impairments associated to a wavelength.
This is a critical step in a transparent dense wavelength division
multiplexing (DWDM) optical islands where a lightpath feasibility has
to be assessed between two regenerations nodes.
This memo provides a framework in which optical parameters can be
considered a control plane. The document relies on information
already present in ITU documents and summarize in term of lightpath
constraints.
"Tunnel Endpoints in BGP", Xiaohu Xu, Paul Francis, 26-Oct-08,
<draft-xu-idr-tunnel-00.txt>
Virtual Aggregation (VA) is a mechanism for shrinking the size of the
DFZ FIB in routers [I-D.francis-idr-intra-va]. VA can result in
longer paths and increased load on routers within the ISP that
deploys VA. This document describes a mechanism that allows an AS
that originates a route to associate a tunnel endpoint terminating at
itself with the route. This allows routers in a remote AS to tunnel
packets to the originating AS. If transit ASes between the remote AS
and the originating AS install the prefixes associated with tunnel
endpoints in their FIBs, then tunneled packets that transit through
them will take the shortest path. This results in reduced load for
the transit AS, and better performance for the customers at the
source and destination.
"Mapped BGP Design", Paul Francis, Xiaohu Xu, Hitesh Ballani, 26-Oct-08,
<draft-francis-mapped-bgp-design-00.txt>
This draft introduces Mapped-BGP, a routing protocol that uses BGP to
distributed tunnel endpoint-to-prefix mappings. The goal of this
draft are to present preliminary concepts and get feedback. It is
not meant to be a fully-formed proposal. The goals of Mapped-BGP
are: 1) to reduce the processing required to run BGP, 2) to speed up
inter-domain convergence, 3) to improve the cross-ISP load balancing
capabilities of BGP, and where possible, 4) to enable forms of
address aggregation like geographical addressing (i.e. for IPv6).
Improved address aggregation is unlikely to be very useful for IPv4,
because most addresses have already been assigned. This design takes
the position that Mapped BGP is useful even without better
aggregation, because 1) FIB size can be reduced through FIB
suppression with Virtual Aggregation, and 2) RIB size per se is not
the growth bottleneck.
"A Modest Proposal for Session Initiation Protocol (SIP) Work in the IETF",
Jonathan Rosenberg, 26-Oct-08, <draft-rosenberg-rai-modest-proposal-00.txt>
The Session Initiation Protocol (SIP) has become widely deployed on
the Internet, covering a wide range of usages from toll bypass to
instant messaging, from service provider to enterprise. However, its
realization in actual deployments differs in important ways from the
specifications. This has created a gulf between existing and ongoing
standards work, and real live deployments. This document argues that
the RAI area should focus on solving real world interoperability
issues and address real world functional gaps.
"A Framework for the Control and Measurement of Wavelength Switched Optical
Networks (WSON) with Impairments", Greg Bernstein, 29-Oct-08,
<draft-bernstein-ccamp-wson-impairments-01.txt>
The operation of optical networks can require a level of detail in
the characterization of network elements, subsystems, devices, and
cabling not typically encountered with other networking technologies.
In addition, these physical characteristics may be important to
consider during typical day-to-day operations such as optical path
establishment and connection monitoring, as well as during the
network planning, installation, and turn-up phases. This document
discusses how the definition and characterization of optical fiber,
devices, subsystems, and network elements contained in various ITU-T
recommendations can be combined with common control and measurement
plane and path computation element technologies to support impairment
aware Routing and Wavelength Assignment (RWA) in optical networks.
"Tunnel Loops and its Detection", Chan-Wah Ng, Benjamin Lim, Mohana
Jeyatharan, 26-Oct-08, <draft-ng-intarea-tunnel-loop-00.txt>
Many protocols in the Internet Protocol suite use packet
encapsulations. This runs into the danger of forming a tunnel loop.
Since each tunnel entry point encapsulates the inner packet with a
tunnel packet header that contains a new hop count, a packet entering
a tunnel loop may be routed infinitely, consuming network resources.
Although there exist methods to cause a packet in a tunnel loop to be
discarded eventually, it would be more desirable to detect the
presence of a tunnel loop and act accordingly. This draft explores
the possibility for tunnel entry points to detect the presence of a
tunnel loop by using an extra identifier tagged to the outer packet
header.
"Information Model for Impaired Optical Path Validation", Greg Bernstein,
26-Oct-08, <draft-bernstein-wson-impairment-info-00.txt>
This document provides an information model for the optical
impairment characteristics of optical network elements for use in
path computation and optical path validation. This model is based on
ITU-T defined optical network element characteristics as given in
ITU-T recommendation G.680 and related specifications. This model is
intentionally compatible with a previous impairment free optical
information model used in optical path computations and wavelength
assignment.
"Extensions to RTCP Feedback Mechanism for Burst Streaming", Orit Levin, Zeev
Vax, 26-Oct-08, <draft-levin-avt-rtcp-burst-00.txt>
This document defines extensions to the "RTCP-Based Feedback"
[RFC4585] to reduce synchronization time when an RTP receiver joins a
multicast stream at a random point in time.
"Delivery of Request-URI Targets to User Agents", Jonathan Rosenberg,
26-Oct-08, <draft-rosenberg-sip-target-uri-delivery-00.txt>
When a Session Initiation Protocol (SIP) proxy receives a request
targeted at a URI identifying a user or resource it is responsible
for, the proxy translates the URI to a registered contact URI of an
agent representing that user or resource. In the process, the
original URI is removed from the request. Numerous use cases have
arisen which require this information to be delivered to the user
agent. This document describes these use cases and defines an
extension to the History-Info header field which allows it to be used
to support those cases.
"Securing RPSL Objects with RPKI Signatures", Robert Kisteleki, Jos Boumans,
26-Oct-08, <draft-kisteleki-sidr-rpsl-sig-00.txt>
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.
"Multi-Session and Multi-Source Transmission in the Real-Time Transport
Protocol (RTP)", Thomas Schierl, Jonathan Lennox, 26-Oct-08,
<draft-schierl-avt-rtp-multi-session-transmission-00.txt>
In this draft, we discuss problems related to multi-session and
multi-source transmission using the Real-Time Transport Protocol
(RTP). Most of the input to this draft is taken from email
discussion. Multi-session and multi-source transmission is motivated
by media data which allows for different transport layer treatment of
parts of the media. This is typically the case for layered media.
Multi-session transmission is when media data from a single media
source is split over multiple RTP sessions. Single-session multi-
source transmission (from now on just called "multi-source
transmission") is when data from a single media source is sent as
several RTP streams in the same RTP session. The main problems
discussed are the mechanisms used for data alignment and source
correlation. This draft gives further an overview of payload formats
using multi-sessions/multi-source transmission and highlights other
transport related issues. The draft concludes with recommendations
for the discussed problems.
"Mobile Agent Discovery Proxy (MADP) in IPv4 Mobility Management", Chunyan
Yao, Bruno Mongazon-Cazavet, 27-Oct-08,
<draft-yao-mip4-mobile-agent-proxy-00.txt>
In some networks such as xDSL networks with WiFi extension, the
periodical transmission of Agent Advertisements (AA) by mobility
agents is used by Mobile Nodes (MN) to detect movement. To allow fast
movement detection, the interval at which AAs are sent should not be
long. In the early deployment of Mobile IPv4 (MIPv4), mobility agents
are deployed in the edge network. For example, in xDSL networks, Home
Agents (HA) and Foreign Agents (FA) are located on or beside Edge
Routers (ER) that usually serves thousands of MNs (typically between
2000 and 5000 in xDSL networks). The periodical transmission of
multicast AA to MNs in such a large network consumes a significant
amount of the aggregation network bandwidth and CPU resources of ERs.
This is a practical problem in xDSL networks with WiFi extension.
This is also a common problem for others access networks in which a
large layer-2 network is served by one router. Hence a Mobility
Agent Discovery proxy (MADP) can be set in access nodes to make the
MNs detect movement fast meanwhile avoiding CPU and network bandwidth
consumption in the aggregation network. The MADP acts as a proxy to
MNs as far as agent discovery is concerned allowing for AS issued by
MNs to be locally replied according to AA issued by HA/FA on the
access network. MADP is a logical function that can be placed on a
suitable node location depending on access network technology and
architecture (i.e. WiMAX) to reduce network resource cost related to
agent discovery.
"Time synchronization method in packet-switched transport network for mobile
backhaul", Li He, Fei Su, 27-Oct-08, <draft-su-tictoc-time-sync-mode-00.txt>
This document introduces a time/phase transfer application mode
employing popular packet-based method IEEE Std 1588-2008 i.e. PTP
with support of common physical layer method Synchronous Ethernet in
a packet-switched transport network for mobile backhaul and a
preliminary thought of time transfer error detection.
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for
ODU0 of Optical Transport Networks Control", Ming Ke, Yuanlin Bao, 27-Oct-08,
<draft-ke-ccamp-gmpls-odu0-00.txt>
This document describes the extensions of GMPLS signaling to control
Optical Transport Networks (OTN) including ODU0 of new optical
channel data unit (ODUk) layer rate.
"A Uniform Resource Name (URN) for Early Warning Emergency Services and
Location-to-Service Translation (LoST) Protocol Usage", Brian Rosen, Henning
Schulzrinne, Hannes Tschofenig, 27-Oct-08,
<draft-rosen-ecrit-lost-early-warning-00.txt>
The Common Alerting Protocol (CAP) is an XML document format for
exchanging emergency alerts and public warnings. Different
organizations issue alerts for specific geographic regions. The
Location-to-Service Translation (LoST) protocol provides a way to
discover servers that distribute these alerts for a geographical
region. This document defines the Service Uniform Resource Names
(URN)s for warnings in the same way as they have been defined with
RFC 5031 for citizen-to-authority emergency services. Additionally,
this document suggests to use LoST for the discovery of servers
distributing alerts.
"Additional Multicast Control Extensions for ANCP", Francois Le Faucheur,
Roberta Maglione, Tom Taylor, 27-Oct-08,
<draft-lefaucheur-ancp-mc-extensions-00.txt>
This memorandum aims at defining additional ANCP protocol extensions
(beyond those already defined) to support some of the Multicast use
cases defined in the ANCP Framework document that are not yet
supported.
"NAT444 with ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira
Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 27-Oct-08,
<draft-shirasaki-nat444-isp-shared-addr-00.txt>
This document describes a network model with ISP Shared Address and
Carrier Grade NAT (CGN) called NAT444. 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.
"On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship",
Wassim Haddad, Mats Naslund, 27-Oct-08,
<draft-haddad-csi-symbiotic-sendproxy-00.txt>
This document introduces a simple mechanism which enables a host
using a cryptographically generated IPv6 address to delegate the task
of secure neighbor discovery to another node, i.e., proxying, by
means of establishing a 'symbiotic' relationship with that node.
"Multiprotocol Label Switching Transport Profile Ring Protection Analysis",
Jian Yang, Hui Su, 27-Oct-08,
<draft-yang-mpls-tp-ring-protection-analysis-00.txt>
The three potential solutions to the MPLS-TP ring protection were
addressed in the report of the IETF-ITU-T Joint Working Team(JWT).
Each solution has different attributes and advantages. This document
provides an analysis for MPLS-TP based on the ring protection.
"Scenario and Solution: Simple IP Multi-homing of the Host", Min Hui, Hui
Deng, 3-Nov-08, <draft-hui-ip-multiple-connections-01.txt>
Current host routing mechanism doesn't allow simple IP multi-homing
for the default gateway consideration. This document proposes a
solution to make multiple connections can work simultaneously.
"Data forwarding behaviour of co-located HA/LMA in PMIP6-MIP6 interactions
scenario C", Kilian Weniger, Genadi Velev, Vijay Devarapalli, 27-Oct-08,
<draft-weniger-netlmm-mip-pmip-forwarding-00.txt>
In PMIP6-MIP6 interactions scenario C, the HA and LMA are co-located
and a transition between MIP6 and PMIP6 is supported without breaking
the session. This draft discusses possible data forwarding
behaviours of the co-located HA/LMA in such scenario. The two
recently discussed options are: 1) data forwarding always according
to the mobile node's MIP6 BCE, if exists, which means that MIP6 BCE
has higher priority than PMIP6 BCE, or 2) data forwarding according
to type of the last received mobility management registration
message, i.e., PMIP6 and MIP6 BCE have equal priority. It is argued
that option 1) increases handover delay by 1 MN-HA RTT and
implementation complexity of the HA/LMA may be higher. Hence, it is
proposed that HA/LMA should behave according to option 2, i.e., MIP6
BCE and PMIP6 BCE have same priority and HA/LMA forwards data
according to the type of the last received mobility management
registration message.
"First-Come First-Serve Source-Address Validation Implementation", Erik
Nordmark, Marcelo Bagnulo, 27-Oct-08, <draft-bagnulo-savi-fcfs-00.txt>
This memo describes FCFS SAVI a mechanism to provide source address
validation for IPv4 and IPv6 networks using the First-Come First-
Serve approach. The proposed mechanism is intended to complement
ingress filtering techniques to provide a higher granularity on the
control of the source addresses used.
"VPLS protection switching with ring access", xiaojuan song, Shaoyong Wu,
Hong Shao, 27-Oct-08, <draft-song-l2vpn-vpls-ring-access-00.txt>
This document introduces a new method to access VPLS network using
ring techonology . This method can improve VPLS access reliability.
Fast switch can be done within 50 ms after link failure detection.
It not only can be used in normal VPLS, but also can be used in VPLS
PBB network.
"Setup of Pseudowires over bi-directional LSP", Wei Cao, 27-Oct-08,
<draft-cao-pwe3-setup-over-bidir-lsp-00.txt>
In MPLS and MPLS-TE environments pseudo wires use two unidirectional
LSPs as PSN tunnels, the two PEs select LSP tunnels independently. In
contrast the MPLS-TP environment supports both bidirectional and
unidirectional LSPs and PWE may, therefore, use bidirectional LSPs as
PSN tunnels.
In order to use MPLS-TP bidirectional LSPs as a PSN tunnels for
pseudo wires some modification of the pseudowire signaling procedures
is required. This draft specifies an extension to LDP that ensures
pseudo-wires are correctly constructed over bi-directional LSPs.
"HIP Mobility and Multihoming Extensions for the Traversal of Network Address
Translators", Jan Melen, Miika Komu, Marcelo Bagnulo, Tom Henderson,
27-Oct-08, <draft-melen-hip-nat-mm-00.txt>
This document defines extensions for HIP mobility and multihoming
mechanisms to operate in network environments with NAT devices. The
extensions are based on the ICE protocol that allows two
communicating end-hosts to establish a direct communications path
with each other even when residing in separate private address
realms. The focus of the extensions in this document is on fault-
tolerance with symmetric locator pairs, and load-balancing is also
discussed. This document also updates RFC5206.
"Miscellaneous Capabilities Negotiation in the Session Description Protocol
(SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 27-Oct-08,
<draft-garcia-mmusic-sdp-misc-cap-00.txt>
SDP has been extended with a capability negotiation mechanism
framework that allows the endpoints to negotiate transport protocols
and attributes. This framework has been extended with a Media
capabilities negotiation mechanism that allows endpoints to negotiate
additional media-related capabilities. This negotiation is embedded
into the widely-used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow
endpoints to negotiate a number of miscellaneous SDP capabilities.
In particular, this memo provides a mechanism to negotiate media
titles ("i=" line for each media), connection data ("c=" line), and
media bandwidth ("b=" line).
"BFD Extensions in Support of Performance Measurement", Xinchun Guo, Mach
Chen, 27-Oct-08, <draft-guo-bfd-pm-extension-00.txt>
This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol to support Performance Measurement for
IP/MPLS network. Specifically, it defines BFD extensions for
measuring packet loss, delay and delay variation for arbitrary paths
between systems.
"DNS64: DNS extensions for Network Address Translation from IPv6 Clients to
IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, Andrew
Sullivan, Masahito Endo, 1-Nov-08, <draft-bagnulo-behave-dns64-01.txt>
DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with NAT64, an IPv6 IPv4 translator to enable client-
server communication between an IPv6-only client and an IPv4-only
server, without requiring any changes to either the IPv6 or the IPv4
node, for the class of applications that work through NATs. This
document specifies DNS64, and provides suggestions on how it should
be deployed in conjunction with NAT64.
"RADIUS Attributes for IPv6 Support", Benoit Lourdelet, Glen Zorn, 2-Nov-08,
<draft-lourdelet-radext-rfc3162bis-02.txt>
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.
"PCN 3-State Encoding Extension in a single DSCP", Bob Briscoe, 27-Oct-08,
<draft-briscoe-pcn-3-in-1-encoding-00.txt>
Pre-congestion notification (PCN) is a mechanism designed to protect
the quality of service of inelastic flows. It does this by marking
packets when traffic load on a link is approaching or has exceeded a
threshold below the physical link rate. This document specifies an
extension to the two-state PCN baseline encoding that enables three
encoding states to be carried in the IP header without using more
than one Diffserv codepoint. It presupposes a standards action has
removed the limit of two encoding states in current tunnelling
mechanisms.
"Representational State Transfer (REST) for Feature Configuration in Session
Initiation Protocol (SIP)", Keith Griffin, Jonathan Rosenberg, 27-Oct-08,
<draft-griffin-bliss-rest-00.txt>
In order to provide interoperable implementations of certain Session
Initiation Protocol (SIP) based features, such as automated call
handling, it is necessary for devices to configure network servers
with feature data. An example is a call forwarding number for a call
forwarding service. This document introduces the concept of
Representational State Transfer (REST) and gives an example of how
REST can be used for such configuration.
"Design for a Nameserver Control Protocol", John Dickinson, Stephen Morris,
Roy Arends, 27-Oct-08, <draft-dickinson-dnsop-nameserver-control-00.txt>
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.
"Deployment Models for PCN-Based Admission Control and Flow Termination Using
Packet-Specific Dual Marking (PSDM)", Michael Menth, 27-Oct-08,
<draft-menth-pcn-psdm-deployment-00.txt>
This document presents different deployment models of PCN-based
admission control (AC) and flow termination (FT) using packet-
specific dual marking (PSDM) for encoding. Their major is that they
require only a single DSCP for packet marking and that they work
reliably in the presence of ingress-egress aggregates (IEAs) with
only a very small average number of flows. Moreover, an advanced
model even works with multipath routing.
"DNS Proxy Implementation Guidelines", Ray Bellis, 27-Oct-08,
<draft-bellis-dnsext-dnsproxy-00.txt>
This document provides guidelines for the implementation of DNS
proxies, as found in broadband routers and other similar network
devices.
"Enabling Source Address Verification via Prefix Reachability Detection",
Wassim Haddad, Mats Naslund, Christian Vogt, 27-Oct-08,
<draft-haddad-prefix-reachability-detection-00.txt>
In this memo, we introduce an approach called "Prefix Reachability
Detection", which aims to address certain man-in-the middle
misbehavior problems and enable a location-based authentication.
"Automatic Call Handling (ACH) Configuration Requirements", Theo
Zourzouvillys, 27-Oct-08,
<draft-zourzouvillys-bliss-ach-config-requirements-00.txt>
This document examines the requirements for a protocol that allows an
agent to configure an ACH enabled proxy.
"PMIPv6 Extensions for Multicast", Hitoshi Asaeda, Pierrick Seite, Jinwei
Xia, 27-Oct-08, <draft-asaeda-multimob-pmip6-extension-00.txt>
This document describes Proxy Mobile IPv6 (PMIPv6) extensions and
solutions to support IP multicast. The Mobile Access Gateway (MAG)
and the Local Mobility Anchor (LMA) are the mobility entities defined
in the PMIPv6 protocol and establish a bi-directional tunnel to
manage mobility for mobile nodes within the Proxy Mobile IPv6 domain.
This document defines the roles of LMA and MAG to support IP
multicast for the mobile nodes.
"Extended Home Link Support for DSMIPv6", Domagoj Premec, 27-Oct-08,
<draft-premec-mext-extended-home-link-00.txt>
Mobile IPv6 Support for Dual Stack Hosts and Routers requires that
the mobile node's home link provides native dual stack support. This
document relaxes this requirement and specifies how a DSMIP6-enabled
mobile node can, with the help of its home agent, maintain
connectivity for both of its home addresses while attached to a home
link that supports only single IP family.
"The A+P Approach to the Broadband Provider IPv4 Address Shortage", Olaf
Maennel, Randy Bush, Luca Cittadini, Steven Bellovin, 3-Nov-08,
<draft-ymbk-aplusp-01.txt>
We are facing the exhaustion of the IANA IPv4 free IP address pool.
Unfortunately, IPv6 is not yet deployed widely enough to fully
replace IPv4, and it is unrealistic to expect that this is going to
change before we run out of IPv4 addresses. Letting hosts seamlessly
communicate in an IPv4-world without assigning a unique globally
routable IPv4 address to each of them is a challenging problem, for
which many solutions have been proposed. Some prominent ones involve
carrier-grade-NATs (CGN), which have been shown to provide an
inadequate experience to IPv4 users and enshrine a walled garden in
the core of the provider. Instead, we propose using specialized NATs
at the consumer premises equipment (CPE) edge which treat some of the
port number bits as part of an extended IPv4 address.
"Diameter MIP6 Feature Vector Additional Bit Allocations", Jouni Korhonen,
27-Oct-08, <draft-korhonen-dime-mip6-feature-bits-00.txt>
During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
Home Agent and the Authentication, Authorization, and Accounting
server may exchange a set of capabilities as defined in. This
document defines additional capability flag bits that are used to
authorize per Mobile Node route optimization, Multiple Care-of
Address and user plane traffic encryption support. Furthermore, this
document also defines a capability flag bit of indicating whether the
Home Agent is authorized to act as a stand alone Virtual Private
Network gateway.
"Extensions to RTSP for the CableLabs Edge Resource Management Interface
Specification (ERMI)", Jean-Francois Mule, Greg White, 27-Oct-08,
<draft-mule-mmusic-rtsp-ermi-extensions-00.txt>
This document provides a description of the RTSP extensions used in
the second version of the CableLabs Edge Resource Manager Interface
specification. It is provided to seek comments from the IETF with
the intent of following the IETF procedures for protocol extensions
and variations. It is a work-in-progress document and future
revisions will contain IANA registrations.
"Issues related to the design choice of IPsec for Mobile IPv6 security",
Basavaraj Patil, Charles Perkins, Hannes Tschofenig, 27-Oct-08,
<draft-patil-mext-mip6issueswithipsec-00.txt>
Mobile IPv6 as specified in RFC3775 relies on IPsec for security. 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 recommends
revisiting this decision in view of the experience gained from
implementation and adoption in other standards bodies.
"Object Naming Service (ONS) Extension for Extensible Supply-chain Discovery
Service (ESDS)", Ning Kong, Xiaodong Li, Seung Jai Yi, 27-Oct-08,
<draft-nkong-esds-ons-00.txt>
Object Naming Service (ONS) is a network service that leverages
Domain Name System (DNS) to discover information about a product and
related services from the Electronic Product Code (EPC). Extensible
Supply-chain Discovery Service (ESDS) is an application layer
protocol for the distributed sharing and discovery of notification
events between associated partners within a supply chain. Unlike DNS
or ONS, where there is a known set of root servers, ESDS will have
numerous roots for various supply chains operating globally. ONS can
be used in collaboration with ESDS to make the multiple ESDS roots be
found easily. This document is intended to extend the ONS to support
ESDS by defining a new Naming Authority PoinTeR (NAPTR) service type
of ONS for ESDS.
"Analysis on how to address NEMO RO for Aeronautics Mobile Networks", Carlos
Bernardos, Marcelo Bagnulo, 3-Nov-08,
<draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt>
The Network Mobility Basic Support protocol enables networks to roam
and attach to different access networks without disrupting the
ongoing sessions that nodes of the mobile network may have. By
extending the Mobile IPv6 support to Mobile Routers, nodes of the
mobile network are not required to support any kind of mobility,
since packets go through the Mobile Router-Home Agent (MRHA) bi-
directional tunnel. Data packets belonging to communications of
nodes of the mobile network have to traverse the Home Agent, and
therefore resulting paths are likely to be suboptimal. Additionally,
the solution adds packet overhead, due to the use of encapsulation
between the Mobile Router and the Home Agent.
There are currently a set of well defined NEMO Route Optimization
requirements for Operational Use in Aeronautics and Space
Exploration, which potential solutions should meet. This document
analyses how the problem of NEMO RO for Aeronautics Mobile Networks
might be tackled, in a way as generic as possible, trying to identify
those open questions and deployment considerations that need to be
addressed.
The main goal of this document is to foster the discussion about
aeronautics NEMO RO solution space within the MEXT WG.
"MPLS Generic Associated Channel", Martin Vigoureux, Matthew Bocci, David
Ward, George Swallow, Rahul Aggarwal, 27-Oct-08,
<draft-bocci-mpls-tp-gach-gal-00.txt>
This document generalises the applicability of the pseudowire
Associated Channel Header (ACH), enabling the realization of a
control channel associated to MPLS Label Switched Paths (LSP), MPLS
pseudowires (PW) and MPLS Sections. In order to identify the presence
of this G-ACH, this document also assigns of one of the reserved MPLS
label values to the 'Generic Alert Label (GAL)', to be used as a
label based exception mechanism.
"Dialog Event foR Identity VErification", J Kuthan, Dorgham Sisalem, Raphael
Coeffic, Victor Pascual, 27-Oct-08, <draft-kuthan-sip-derive-00.txt>
This document provides a simple mechanism to prevent an attacker from
presenting a forged "From" header field. It offers an end-to-end
identity assumption which does not require any previous association
or trust relationship between administrative domains or the UAs. The
UAS verifies the "From" header by subscribing to the Dialog Event
package [RFC 4235] at the AOR in the "From" header field. If the
entity calling is registered under this AOR, it will confirm that it
is calling by sending some valid dialog state. In this case, the
identity of the caller is considered to be verified.
"Definition of Managed Objects for the MANET Optimized Link State Routing
Protocol version 2", Robert Cole, Thomas Clausen, 27-Oct-08,
<draft-cole-manet-olsrv2-mib-00.txt>
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 and managing
aspects of the Optimized Link State Routing protocol version 2. The
Optimized Link State Routing MIB also reports state information,
performance metrics, and notifications. In addition to
configuration, this additional state and performance information is
useful to management stations troubleshooting Mobile Ad-Hoc Networks
routing problems.
"OAM Configuration Framework and Requirements for GMPLS RSVP-TE", Attila
Takacs, Don Fedyk, He Jia, 3-Nov-08,
<draft-takacs-ccamp-oam-configuration-fwk-01.txt>
OAM functions are essential to ensure that the desired service level
of traffic engineered connections are met. In certain technologies
OAM entities are inherently established once the connection is set
up. However other technologies, especially OAM for packet switched
networks, require an extra configuration step after connection
establishment to setup OAM entities. This document specifies
extensions to RSVP-TE to support the establishment and configuration
of OAM entities along with LSP signalling.
"The MANET Link Type", Thomas Clausen, 27-Oct-08,
<draft-clausen-manet-linktype-00.txt>
This document describes the link characteristics and properties for
links over which MANET protocols are designed to operate.
"Harmless IPv6 Address State Extension (Uncertain State)", Hiroshi Kitamura,
Shingo Ata, Masayuki Murata, 27-Oct-08,
<draft-kitamura-ipv6-uncertain-address-state-00.txt>
This document describes a new IPv6 address state called "Uncertain"
address state as an extension of IPv6 address state specification.
"Uncertain" address state is designed to introduce two
functionalities. One is to achieve "Address Reservation" function.
The other is to avoid a DAD (Duplicate Address Detection) time
consuming problem for dynamically created addresses.
"Uncertain" Address State is inserted between "Tentative" address
state and "Valid" address state. After "Tentative" address state
(DAD operation has finished) for a newly created address, its state
will enter to "Uncertain" address state. While an address stay at
"Uncertain" address state, the address is behaved as if it is
reserved by the node exclusively. (The other nodes can not obtain
such a reserved address.) When it becomes really necessary for the
node to utilize the reserved address, its address state is changed
into "Valid" address state without accompanying time consuming DAD
operation. By these procedures, we can avoid the DAD problem.
"PIM Multi-Topology ID (MT-ID) Join-Attribute", Yiqun Cai, Heidi Ou,
27-Oct-08, <draft-cai-pim-mtid-00.txt>
This document introduces a new type of PIM Join Attribute that
extends PIM signaling to identify a topology that should be used when
constructing a particular multicast distribution tree.
"Forward Error Correction Grouping Semantics in Session Description
Protocol", Ali Begen, 27-Oct-08, <draft-begen-mmusic-rfc4756bis-00.txt>
The Session Description Protocol (SDP) supports grouping media lines.
SDP also has semantics defined for grouping the associated source and
Forward Error Correction (FEC)-based repair flows. However, the
semantics that were defined in RFC 4756 generally fail to provide the
specific grouping relationships between the source and repair flows
when there are more than one source and/or repair flows in the same
group. Furthermore, the existing semantics also do not support
additive repair flows and prioritization among the repair flows
protecting one or more source flows. This document addresses these
issues by introducing new FEC grouping semantics.
"DHCPv6 and CGA Interaction: Problem Statement", Sheng Jiang, Sean Shen,
27-Oct-08, <draft-jiang-csi-dhcpv6-cga-ps-00.txt>
This document presents a problem statement for the possible
interactions between DHCPv6 and CGA. Firstly, in order to support the
co-existing scenarios of DHCPv6 and CGA, Some operations are
clarified for the interaction of DHCPv6 servers and CGA-associated
hosts. Then, some extended scenarios are also discussed in this
document, including using CGAs in DHCPv6 operations to enhance the
security features and using DHCPv6 to serve the CGA generation.
"IPv6-to-IPv6 Network Address Translation (NAT66)", Margaret Wasserman, Fred
Baker, 3-Nov-08, <draft-mrw-behave-nat66-01.txt>
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.
This document also describes an address mapping option for NAT66 that
offers the topology hiding benefit associated with NAT44 at the cost
of additional state in the NAT66 device.
"Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Many-to-Many Text Chat",
Peter Saint-Andre, Salvatore Loreto, Fabio Forno, 27-Oct-08,
<draft-saintandre-sip-xmpp-groupchat-00.txt>
This document defines a bi-directional protocol mapping for the
exchange of instant messages in the context of a many-to-many chat
session among users of the Session Initiation Protocol (SIP) and
users of the Extensible Messaging and Presence Protocol (XMPP).
Specifically for SIP text chat, this document specifies a mapping to
the Message Session Relay Protocol (MSRP).
"DHCP Options for Conveying Port Mask and Port Range Router IP Address",
Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain Villefranque,
29-Oct-08, <draft-boucadair-dhc-port-range-01.txt>
This draft defines two new DHCP (Dynamic Host Configuration Protocol,
[RFC2131]) Options to be used in the context of Provider-Provisioned
CPE solution (a.k.a. Port Range solution or Fractional Address).
The first option is used to convey a Port Mask and the second one may
be used to convey a list of Port Range Router IP addresses.
"MPLS-TP OAM Framework and Overview", Italo Busi, Ben Niven-Jenkins,
27-Oct-08, <draft-busi-mpls-tp-oam-framework-00.txt>
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
based on a profile of the MPLS and pseudowire (PW) procedures as
specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW)
and multi-segment PW (MS-PW) architectures complemented with
additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching management
for packet transport applications that do not rely on the presence of
a control plane.
This document provides a framework for supporting the MPLS-TP OAM
requirements .[10] in a manner that admits a comprehensive set of OAM
procedures.
"Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Jegadish
Devadoss, Joerg Ott, Igor Curcio, 27-Oct-08,
<draft-ott-avt-rtcp-overlay-multicast-00.txt>
The Real-time Transport Control Protocol(RTCP) is designed to operate
along with Real-time Transport Protocol(RTP) in unicast, single-
source multicast and any-source multicast environments. With the
availability of overlay multicast, the suitability of RTCP in such an
environment need to be analyzed. The applicability of the existing
RTCP reporting architectures in an overlay multicast environment is
investigated and the new features that may be required are discussed
in this document.
"BGP Bestpath Selection Criteria", Rajiv Asati, 27-Oct-08,
<draft-asati-idr-bgp-bestpath-selection-criteria-00.txt>
BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as
one of the key 'Route Resolvability Condition' that must be satisfied
before the BGP bestpath candidate selection. This condition, however,
may not be sufficient (as explained in the Appendix section) and
desire further granularity.
"Framework for Content Push Delivery over the Session Initiation Protocol
(SIP)", Martin Dolly, Kent Bogestam, Salvatore Loreto, 27-Oct-08,
<draft-mdolly-sipping-push-00.txt>
This document specifies a protocol for push delivery protocol over
SIP. The purpose is to allow an application on a UA to subscribe to
updates to its own application events containing either content or
references to the content. This document describes how content can
be pushed out to an application by the use of push events. As part
of this framework, a new SIP event package is defined for
notification of push events for content delivery.
"Presence & Instant Messaging Provisioning", Avshalom Houri, Gil Perzy, Edwin
Aoki, Sriram Parameswar, 27-Oct-08,
<draft-houri-speermint-presence-im-provision-00.txt>
NOTE: This is still an initial draft of this document
The document defines data for provisioning between two presence and
IM domains and the methods that can be used to convey the data
between the domains.
"Virtual IPv6 Connectivity for IPv4-Only Networks", Christian Vogt, Alain
Durand, 27-Oct-08, <draft-vogt-durand-virtual-ip6-connectivity-00.txt>
This document proposes Virtual IPv6 Connectivity, a method for
deployment in IPv4-only networks to enable communications with the
IPv6 Internet. Virtual IPv6 Connectivity uses IP protocol
translation to support both incoming traffic from IPv6 to IPv4, and
outgoing traffic from IPv4 to IPv6. Communications initiated into
the latter direction are facilitated through DNS or DNSSEC proxies.
Different than existing IPv4/IPv6 interworking techniques, which are
for deployment in IPv6 networks, Virtual IPv6 Connectivity does not
require extra, globally unique IPv4 addresses.
"AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David
McGrew, 27-Oct-08, <draft-mcgrew-srtp-aes-gcm-00.txt>
This document defines how AES GCM, AES CCM, and other Authenticated
Encryption with Associated Data (AEAD) algorithms, can be used to
provide confidentiality and data authentication mechanisms in the
SRTP protocol.
"Periodic Retrieval of Location Information by Devices and Location
Information Servers", Mary Barnes, 27-Oct-08,
<draft-barnes-periodic-location-retrieval-00.txt>
The base HTTP Enabled Location Delivery (HELD) protocol includes
options for retrieving location information from a LIS by a Device.
Some networks require the ability for the device to periodically
request location information from the LIS and/or for the LIS to
periodically request location information from the device.
Extensions to base HELD allow a Device to establish a context with a
LIS and negotiate capabilities of the Device in terms of providing
location information. The measurement extensions to base HELD allow
the LIS to request location information from a Device. This document
provides an overview of the requirements and a solution using HELD
and HELD extensions to support the periodic request of location information,
both by a Device from an LIS and by the LIS from a Device, depending upon
the specific scenario and measurement capabilities of the Device.
"RBridge VLAN Mapping", Radia Perlman, Dinesh Dutt, Donald Eastlake 3rd,
27-Oct-08, <draft-perlman-trill-rbridge-vlan-mapping-00.txt>
Some bridge products perform a feature known as "VLAN mapping", in
which a bridge translates a data frame's VLAN ID from one VLAN to
another when it forwards a frame from one port to another. This
feature facilitates scenarios such as combining two bridged LANs with
overlapping VLAN IDs into one bridged LAN without merging two
communities just because they have been given the same VLAN ID in the
original two clouds. This document describes how RBridges can achieve
the same functionality.
"Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing
for the Automatically Switched Optical Network (ASON)", Lyndon Ong, Janathan
Sadler, Stephen Shew, 27-Oct-08, <draft-many-ccamp-4258bis-00.txt>
The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols has been defined to control different switching
technologies as well as different applications. These include
support for requesting Time Division Multiplexing (TDM) connections
including Synchronous Optical Network (SONET)/Synchronous Digital
Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates
on the routing requirements placed on the GMPLS suite of protocols in order
to support the capabilities and functionalities of an Automatically Switched
Optical Network (ASON) as defined by the ITU-T.
"Threshold Secret Sharing", David McGrew, Praveen Patnala, 27-Oct-08,
<draft-mcgrew-tss-00.txt>
Threshold secret sharing (TSS) provides a way to generate N shares
from a value, so that any M of those shares can be used to
reconstruct the original value, but any M-1 shares provide no
information about that value. This method can provide shared access
control on key material and other secrets that must be strongly
protected.
This note defines a threshold secret sharing method based on
polynomial interpolation in GF(256) and a format for the storage and
transmission of shares. It also provides usage guidance, describes
how to test an implementation, and supplies test cases.
"LSA Correlation to Schedule Routing Table Calculations", Mukul Goyal, G
Choudhury, Aman Shaikh, Kishor Trivedi, Hossein Hosseini, 27-Oct-08,
<draft-goyal-ospf-lsacorr-00.txt>
OSPF requires a router to recalculate its routing table whenever it
receives a new router or network LSA. However, a topology change,
such as a router down event, may cause a number of new LSAs to be
generated. These LSAs may arrive at a router at different times. In
order to avoid several routing table calculations in quick succession
in such cases, commercial routers enforce a hold time between
successive routing table calculations. The hold time based schemes,
while limiting the number of routing table calculations, may also
cause undesirable delays in convergence to the topology change. This
ID describes an alternate approach to schedule routing table
calculations, called LSA Correlation. Rather than using individual
LSAs as triggers for routing table calculations, LSA Correlation
scheme correlates the information in the LSAs to identify the
topology change. A routing table calculation can be performed when
the topology change has been identified, which could span multiple
LSAs.
"Mechanism for performing LSP-Ping over RSVP protection paths", Nitin
Bahadur, Kireeti Kompella, 27-Oct-08,
<draft-nitinb-lsp-ping-rsvp-protection-00.txt>
This document describes methods for performing lsp ping over mpls
rsvp-te protection paths, when the protection paths are not in use.
Conventional LSP-Ping follows the same path as data traffic. In some
cases, it might be useful to follow the data path of protection paths
(detours and bypasses) to ensure that the those paths are fully
functional. This document describes enhancements to LSP-Ping to
perform ping over such paths.
"Considerations for IPv6 Address Selection Policy Changes", Tim Chown,
3-Nov-08, <draft-chown-addr-select-considerations-01.txt>
Through operational experience of IPv6 Default Address Selection
(RFC3484) [1] implementations, it appears that a requirement has
arisen for hosts and networks to be able to have their policies for
address selection updated. This text discusses considerations for
such policy changes, e.g. 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
RFC3484, where default policies are currently defined.
"VPLS Flush in BGP-based Virtual Private LAN Service", Bhupesh Kothari, Rex
Fernando, 27-Oct-08, <draft-kothari-l2vpn-vpls-flush-00.txt>
This document defines procedures that allow BGP based Virtual Private
LAN Service (VPLS) provider edge (PE) devices to send explicit flush
notifications to remote VPLS PEs.
"Comcast's ISP Experiences In a Recent P4P Technical Trial", Chris Griffiths,
Jason Livingood, Richard Woundy, 28-Oct-08,
<draft-livingood-woundy-p4p-experiences-02.txt>
This document describes the experiences of Comcast, a large cable
broadband Internet Service Provider (ISP) in the U.S., in a recent
Proactive Network Provider Participation for P2P (P4P) technical
trial. This trial used iTracker technology being considered by the
IETF, as part of what is currently known as the Application Layer
Transport Optimization (ALTO) Birds of a Feather (BoF).
"TANA Practices and Recommendations", Reinaldo Penno, Janardhan Iyengar,
3-Nov-08, <draft-penno-tana-app-practices-recommendation-01.txt>
Applications routinely open multiple TCP connections. For example,
P2P applications maintain connections to a number of different peers
while web browsers perform concurrent download from the same web
server. Application designers pursue different goals when doing so:
P2P apps need to maintain a well-connected mesh in the swarm while
web browsers mainly use multiple connections to parallelize requests
that involve application latency on the web server side. But this
practice also has impacts to the host and the network as a whole. For
example, an application can obtain a larger fraction of the
bottleneck than if it had used fewer connections. Although capacity
is the most commonly considered bottleneck resource, middlebox state
table entries are also an important resource for an end system
communication.
This documents clarifies the current practices of application design
and reasons behind them, and discusses the tradeoffs surrounding the
use of many concurrent TCP connections to one destination and/or to
different destinations. Other resource types may exist, and the
guidelines are expected to comprehensively discuss them.
"Metadata Striping for pNFS", Mike Eisler, 27-Oct-08,
<draft-eisler-nfsv4-pnfs-metastripe-01.txt>
This Internet-Draft describes a means to add metadata striping to
pNFS.
"Separating Control and Data Plane for Proxy Mobile IPv6", Vijay Devarapalli,
27-Oct-08, <draft-devarapalli-netlmm-pmipv6-data-plane-00.txt>
Proxy Mobile IPv6 is a network-based mobility management protocol.
The mobility entities involved in the Proxy Mobile IPv6 protocol, the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA),
setup tunnels dynamically to manage mobility for a mobile node within
the Proxy Mobile IPv6 domain. This document describes an extension
to the Proxy Mobile IPv6 protocol to register a data plane address,
that is different from the Proxy Care-of Address with the LMA. This
allows separation of control and data plane.
"Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic
combinations of ciphers and MACs)", David McGrew, 27-Oct-08,
<draft-mcgrew-aead-aes-cbc-hmac-sha1-00.txt>
This document specifies algorithms for authenticated encryption with
additional authenticated data (AEAD) that are based on the
composition of the Advanced Encryption Standard (AES) in the Cipher
Block Chaining (CBC) mode of operation for encryption, and the HMAC-
SHA1 message authentication code (MAC). It also separately defines a
generic composition method that can be used with other MACs and
randomized ciphers (that is, ciphers that use random initialization
vectors).
These algorithms are randomized, and thus are suitable for use with
applications that cannot provide distinct nonces to each invocation
of the AEAD encrypt operation.
"Storage De-Duplication Awareness in NFS", Mike Eisler, 27-Oct-08,
<draft-eisler-nfsv4-pnfs-dedupe-00.txt>
This Internet-Draft describes a means to add awareness of de-
duplication storage to NFS.
"Geopriv Concerns about SIP Location Conveyance Retransmission
Recommendations Document", James Polk, 27-Oct-08,
<draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt>
This document expresses grave concerns about the recommendations
made in the 'Implications of <retransmission-allowed>' document,
which in turn states several recommendations towards the
modification of SIP Location Conveyance. This document makes
several counterproposals to what is currently in the 'Implications
of <retransmission-allowed>' document.
"DRINKS Use cases and Protocol Requirements", Sumanth Channabasappa,
3-Nov-08, <draft-channabasappa-drinks-usecases-requirements-01.txt>
This document presents use cases that illustrate what constitutes
session establishment data, the functional components that need them,
and the protocol requirements for provisioning and managing session
establishment data within the identified functional components.
"ALTO Information Export Service", Stanislav Shalunov, Reinaldo Penno,
Richard Woundy, 27-Oct-08, <draft-shalunov-alto-infoexport-00.txt>
The ALTO Information Export Service is a simple way to convey ISP
routing policy preferences to applications. Applications that could
use this service are those that have a choice in connection
endpoints. Examples of such applications are peer-to-peer and
content delivery networks.
Applications already have access to great amount of underlying
topology information. For example, views of the Internet routing
table are easily available at looking glass servers and entirely
practical to download to every client. What is missing is the
routing policy information -- what does the local ISP actually
prefer?
This document describes a very simple mechanism that would allow to
export such information to applications. While such service would
primarily be provided by the network, i.e., the local ISP, third
parties could also operate this service.1. Requirements notation
"RTP Payload format for Application and Desktop Sharing", Omer Boyaci,
Henning Schulzrinne, 27-Oct-08, <draft-boyaci-avt-app-sharing-00.txt>
This document defines a protocol to support accessing general
graphical user interface (GUI) desktops and applications remotely,
either by a single remote user or embedded into a multiparty
conference. The protocol is designed to allow sharing of, and access
to general windowing system applications that have not been expressly
written to be accessed remotely.
"BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, 27-Oct-08,
<draft-pmohapat-sidr-pfx-validate-00.txt>
A BGP route associates an address prefix with a set of autonomous
systems (AS) that identify the interdomain path the prefix has
traversed in the form of BGP announcements. This set is represented
as the AS_PATH attribute in BGP and starts with the AS that
originated the prefix. To help reduce well-known threats against BGP
including prefix hijacking and monkey-in-the-middle attacks, one of
the security requirements is the ability to validate the origination
AS of BGP routes. More specifically, one needs to validate that the
AS number claiming to originate an address prefix (as derived from
the AS_PATH attribute of the BGP route) is in fact authorized. This
document describes a simple validation mechanism to partially satisfy
this requirement.
"On the implementation of TCP urgent data", Fernando Gont, Andrew
Yourtchenko, 27-Oct-08, <draft-gont-tcpm-urgent-data-00.txt>
This document analyzes the current practices for handling TCP urgent
data in the current Internet. It describes how popular TCP
implementations process urgent data, and also describes how a number
of middle-boxes affect how urgent data is processed by end systems.
Additionally, it includes a survey of the processing of urgent data
by popular TCP implementations. This document updates the relevant
specifications such that they accommodate current practice in
processing TCP urgent data.
"On the generation of TCP timestamps", Fernando Gont, 27-Oct-08,
<draft-gont-tcpm-tcp-timestamps-00.txt>
This document describes an algorithm for selecting the timestamps (TS
value) used for TCP connections that use the TCP timestamp option,
such that the resulting timestamps are monotonically-increasing
across connections that involve the same four-tuple {local IP
address, local TCP port, remote IP address, remote TCP port}. The
properties of the algorithm are such the possibility of an attacker
guessing the exact value is reduced. Additionally, it describes an
algorithm for processing incoming SYN segments to allow a higher
connection establishment rates to any TCP end-point.
"Evolution of the IP Model", Dave Thaler, 3-Nov-08,
<draft-iab-ip-model-evolution-01.txt>
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.
"IPv4/v6 NAT With Explicit Control (NAT-XC)", Keith Moore, 3-Nov-08,
<draft-moore-nat-xc-01.txt>
This document describes a mechanism called NAT-XC (for NAT with
Explicit Control) for translating between IPv4 and IPv6. NAT-XC is
distinguished from other IPv4/IPv6 translations schemes in that it
separates the translation between IPv4 and IPv6 from the management
of address bindings for such a translation; and is designed to allow
applications to be explicitly aware of, and control, their address
bindings. NAT-XC appears to be usable in a wide variety of scenarios
requiring communication across IPv4/IPv6 boundaries.
"Healthy Food and Special Dietary Requirements for IETF meetings", Mary
Barnes, 27-Oct-08, <draft-barnes-healthy-food-00.txt>
This document describes the basic requirements for food for folks
that attend IETF meetings require special diets, as well as those
that prefer to eat healthy. While, the variety of special diets is
quite broad, the most general categories are described. There can be
controversy as to what constitutes healthy eating, but there are some
common, generally available foods that comprise the basis for healthy
eating and special diets. This document provides some
recommendations to meeting planners, as well as participants, in
handling these requirements.
"Security implications of Network Address Translators (NATs)", Fernando Gont,
4-Nov-08, <draft-gont-behave-nat-security-01.txt>
This document analyzes the security implications of Network Address
Translators (NATs). It neither deprecates nor encourages the use of
NATs, but rather aims to raise awareness about their security
implications, and possible implementation approaches to improve their
security.
"RELOAD Node Operations Proposal", Bruce Lowekamp, 27-Oct-08,
<draft-lowekamp-p2psip-nodefetch-00.txt>
This document defines a set of methods for Node-specific operations
as part of the REsource LOcation And Discovery (RELOAD) protocol.
This document defines NodeFetch, NodeStore, and NodeRemove methods
that allows manipuation of Node specific usage data. These methods
will be useful for multiple diagnostic, administrative, and discovery
usages. Because of their usefulness for a variety of expected
usages, these methods are advanced for inclusion in the base RELOAD
protocol.
"Client MIP6 Binding Revocation Using Auth Option", Ahmad Muhanna, Mohamed
Khalil, Alper Yegin, Frank Xia, 27-Oct-08,
<draft-muhanna-mext-revocation-using-authoption-00.txt>
This document describes the use of the Authentication Protocol in
protecting binding revocation signaling messages between the home
agent and the mobile node. The home agent uses this mechanism to
revoke a client mobile IPv6 binding cache entry that was created
using Client Mobile IPv6 protocol signaling with authentication
protocol.
"Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against
Off-Path Spoofing Attacks", Steven Blake, 3-Nov-08,
<draft-blake-ipv6-flow-label-nonce-01.txt>
TCP and other transport-layer protocols are vulnerable to spoofing
attacks from off-path hosts. These attacks can be prevented through
the use of cryptographic authentication. However, it is difficult to
use cryptographic authentication in all circumstances. A variety of
obfuscation techniques -- such as initial sequence number
randomization and source port randomization -- increase the effort
required of an attacker to successfully guess the packet header
fields which uniquely identify a transport connection. This memo
proposes the use of the IPv6 Flow Label field as a random, per-
connection nonce value, to add entropy to the set of packet header
fields used to identify a transport connection. This mechanism is
easily implementable, allows for incremental deployment, and is fully
compliant with the rules for Flow Label use defined in RFC 3697.
"DHCP options for Access Point Name and attach type indication", Basavaraj
Patil, Kuntal Chowdhury, 27-Oct-08,
<draft-patil-dhc-apn-attachtype-options-00.txt>
Cellular data networks which are based on 3GPP standards use the
concept of Access Point Name. A mobile node which attaches via a
3GPP access network indicates thru layer 2 signaling the access point
name to which connectivity is desired. This document specifies a
DHCP option which enables the mobile node to request the access point
name in DHCP messages. A mobile node whose mobility is managed by
the network using Proxy Mobile IPv6 protocol may perform a handover
from one access technology to another. A DHCP option which enables
the host to indicate if the attachment via the new interface is a
handover or another connction is also specified.
"Architecture and Practice for VoIP Lawful Interception Using Session Border
Controller(SBC)", Menghui Yang, XiaoDong Lee, Wei Mao, 27-Oct-08,
<draft-yang-sipping-voipli-00.txt>
Recently broadband Voice over IP (VoIP) has a clear trend to
substitute for traditional telephone services such as wire telephone,
wireless telephone and mobile telephone service, it has become
increasingly clear that VoIP services will be expected to provide
Lawful Intercept to the same level experienced in the Public Switched
Telephone Network(PSTN)[7]. In an effort to provide lawful
interception for broadband VoIP, an architecture using session border
controller was proposed, and a prototype implementation of the
broadband VoIP lawful interception was created and basic performance
evaluation was conducted on this prototype system. This document
reports on the prototype implementation and the test results.
"Diameter Routing Problem Statement", Tina Tsou, 27-Oct-08,
<draft-tsou-dime-routing-problem-statement-00.txt>
This document describes use cases that suggest requirements to be
able to add constraints to the existing Diameter routing mechanisms.
"Creation of a registry for DNS SRV record protocol names", Olafur
Gudmundsson, 27-Oct-08, <draft-gudmundsson-dns-srv-iana-registry-00.txt>
DNS SRV record was specified in RFC2052 and RFC2782. These two RFC
did not specify an IANA registry for names of the protocols using SRV
records. This document creates such a registry.
"PCECP Requirements and Extensions of Alternate Routing for Wavelength
Switched Optical Networks", Dajiang Wang, Zhenyu Wang, Qimin Xiang, Feng Gao,
27-Oct-08, <draft-wang-pce-wson-alternate-routing-00.txt>
This memo provides application-specific requirements and extensions
of alternate routing for the support of Wavelength Switched Optical
Networks (WSON).
"OAuth Access Tokens using credentials", Bill de Hora, Stephen Farrell,
27-Oct-08, <draft-dehora-farrell-oauth-accesstoken-creds-00.txt>
OAuth Access Tokens using credentials is a technique for allowing
user agents to obtain an OAuth access token on behalf of a user
without requiring user intervention or HTTP redirection to a browser.
OAuth itself is documented in the OAuth Core 1.0 Specification.
"Look Up Function vs. Location Routing Function discussion", Greg Schumacher,
Hadriel Kaplan, 3-Nov-08, <draft-schumacher-drinks-luf-lrf-diff-01.txt>
This document provides a comparison between the Look Up Function
(LUF) and the Location Routing Function (LRF) as used for inter and
intra-domain SIP session routing. It also develops the relationship
between the two functions. This document is meant for discussion
purposes only.
Schumacher
Expires May 3, 2009
[page 1]
Look Up Function vs. Location Routing Function discussion
Nov 2008
"Rapid Synchronisation of RTP Flows", Colin Perkins, 27-Oct-08,
<draft-perkins-avt-rapid-rtp-sync-00.txt>
This memo outlines how RTP multimedia sessions are synchronised, and
discusses how rapidly such synchronisation can occur. It is shown
that unicast sessions can be synchronised immediately in most cases.
Multicast groups have longer synchronisation delay. A modification
to the RTCP timing rules is suggested to improve synchronisation time
for SSM senders. A new RTP/AVPF feedback packet is defined to
improve general synchronisation times.
"Extreme Networks' Ethernet Automatic Protection Switching (EAPS), Version
1.3", S Shah, 27-Oct-08, <draft-shah-extreme-rfc3619bis-00.txt>
This document describes version 1.3 of the Ethernet Automatic
Protection Switching (EAPS) (TM) technology invented by Extreme
Networks to increase the availability and robustness of Ethernet
rings. An Ethernet ring built using EAPS can have resilience
comparable to that provided by SONET rings, at lower cost and without
some of the constraints (e.g. ring size) of SONET.
"Report on first GMPLS Controlled Ethernet tests", Attila Takacs, Benoit
Tremblay, Remi Theillaud, Kenichi Ogaki, 27-Oct-08,
<draft-takacs-ccamp-gels-tests-00.txt>
In this memo we report on the first GMPLS controlled Ethernet
interoperability test involving three independent implementations.
We also briefly introduce our GMPLS controlled Ethernet test-beds and
identify the implemented GMPLS extensions.
Note, this memo does not intend to specify any GMPLS extension.
"The Solution for Pmipv6 Multicast Service", Yuankui Zhao, Pierrick Seite,
3-Nov-08, <draft-zhao-multimob-pmip6-solution-02.txt>
To mobility scenario, multicast service is a valuable feature to
those mobile customers. We need to consider how to integrate current
multicast service in PMIPv6 domain. This draft will introduce this
kind of solution about proxy mobile multicast. It explains the
system consideration about how to provide the proxy mobile multicast
system.
"Line identification in IPv6 Router Solicitation messages", Suresh Krishnan,
Alan Kavanagh, 3-Nov-08, <draft-krishnan-6man-rs-mark-01.txt>
In ethernet based aggregation networks, several subscriber premises
may be 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.
"Load Balancing based on IPv6 Anycast and pseudo-Mobility", Wanming Luo,
XiaoDong Lee, Wei Mao, Mei Wang, 3-Nov-08,
<draft-luo-v6ops-6man-shim6-lbam-00.txt>
Load balancing is a key factor for both IPv4 to IPv6 transition
mechnisms, e.g.NAT-PT or Tunnel broker, and Multihoming to improve
their scalability and Robustness. In fact, that is a method, by
which IP packet can be distributed across a pool of servers, instead
of directing to a single server.Load balancing has been widely used
by NAT, Web service and FTP service. However, current load balancing
software and implementations have problems such as poor scalability,
inability to balance session flow, long latency time and topological
constraint on server pool.
"Multicast VPN fast upstream failover", Thomas Morin, Yakov Rekhter, Rahul
Aggarwal, Praveen Muley, 3-Nov-08,
<draft-morin-l3vpn-mvpn-fast-failover-00.txt>
This document defines multicast VPN extensions and procedures that
allow fast failover for upstream failures, by allowing downstream PEs
to take into account the status of Provider-Tunnels (P-tunnels) when
selecting the upstream PE for a VPN multicast flow, and extending BGP
mVPN routing so that a C-multicast route can be advertised toward a
standby upstream PE.
"Fast Hello exchange procedures for Protocol Independent Multicast", Thomas
Morin, 4-Nov-08, <draft-morin-pim-fast-hello-00.txt>
This document is proposed as an update of RFC4601 and describes
procedures allowing exchanges of PIM Hellos to complete earlier when
a new link comes up, to mitigate the multicast traffic blackholing
issues that result from inconsistencies between links advertised by
unicast routing and the links on which PIM adjacencies are fully set
up.
"Interworking between MPLS-TP and IP/MPLS", Riccardo Martinotti, Diego
Caviglia, Nurit Sprecher, 17-Nov-08,
<draft-martinotti-mpls-tp-interworking-00.txt>
Purpose of this ID is to illustrate interworking scenarios between
network(s) supporting MPLS-TP and network(s) supporting IP/MPLS.
Main inteworking issues and open points are highlighted.
"IP Router Alert Considerations and Usage", Reshad Rahman, 17-Nov-08,
<draft-rahman-rtg-router-alert-considerations-00.txt>
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 and IGMP are some of the protocols which make use of the IP
Router Alert option. This document discusses security aspects and
common practices around the use of router alert and discusses
consequences on the use of router alert by existing or new
applications. Common practices in router alert implementation
facilitating router protection are also discussed. Finally a
possible enhancement to the current specification of Router Alert is
presented for feedback.
"Mobile IPv6 IPsec Route Optimization (IRO)", Arnaud Ebalard, 17-Nov-08,
<draft-ebalard-mext-ipsec-ro-00.txt>
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.
"Border Router Discovery Protocol (BRDP) Based Routing", Teco Boot,
17-Nov-08, <draft-boot-brdp-based-routing-00.txt>
This document specifies a mechanism for routing in multi-homed edge
networks. The default gateway routing mechanism is replaced with
routing to Border Routers that correspond with the source address of
the packets.
"Using the Router Alert Option for Packet Interception in GIST", Robert
Hancock, 17-Nov-08, <draft-hancock-nsis-gist-rao-00.txt>
The Generic Internet Signalling Transport (GIST) protocol depends on
packet interception to identify the nodes that should participate in
signalling sessions. The base protocol assumes n-tuple analysis of
the packet header as the interception algorithm. This document
describes an experimental extension to GIST to use the Router Alert
Option (RAO) to enhance interception efficiency. It describes the
tradeoffs in using such an approach including the impact on legacy
equipment and protocol deployability, and also the considerations to
be taken into account in selecting values for the RAO value field.
"Context Reflection: Context Transfer for Proxy Mobile IPv6", Ryuji Wakikawa,
Sawako Kiriyama, Jinwei Xia, 17-Nov-08, <draft-wakikawa-pmip-ct-00.txt>
This document introduces a simple Context Transfer mechanism for
Proxy Mobile IPv6. This context transfer mechanism can carry
information of a mobile node between mobility anchor gateways without
any assumption of inter-MAG trust nor direct connectivity.
"Hierarchical OLSR", Yannick Lacharite, Maoyu Wang, Pascale Minet, Thomas
Clausen, 18-Nov-08, <draft-lacharite-manet-holsr-01.txt>
This document describes the Hierarchical Optimized Link State Routing
(HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this
specification a heterogeneous mobile ad hoc network is defined as a
network of mobile nodes that are characterized by different
communication capabilities, such as communication channels,
processing powers or energy levels.
The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR
takes advantage of the node's distinct communications capabilities to
reduce the routing control overhead in large heterogeneous ad hoc
networks, thus improving the performance of the routing mechanism.
More precisely, HOLSR defines a hierarchy in the network and presents
a routing scheme for this hierarchical structure with a better
scalability.
"An IRI/URI Namespace for International Object Identifiers (OIDs)", John
Larmouth, Olivier Dubuisson, 18-Nov-08, <draft-larmouth-oid-iri-00.txt>
This internet draft defines the IRI/URI scheme for International
Object Identifiers. The syntax and semantics of the IRI is specified
below using the International Object Identifier tree specified in
[ITU-T X.660].
"The Remote Framebuffer Protocol", Tristan Richardson, John Levine,
18-Nov-08, <draft-levine-rfb-00.txt>
RFB ("remote framebuffer") is a simple protocol for remote access to
graphical user interfaces which allows a client to view and control a
window system on another computer. Because it works at the
framebuffer level RFB is applicable to all windowing systems and
applications. This document describes the protocol used to
communicate between an RFB client and RFB server. RFB is the
protocol used in VNC, Virtual Network Computing.
"BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral,
18-Nov-08, <draft-bhatia-bfd-crypto-auth-00.txt>
This document proposes an extension for Bidirectional Forwarding
Detection (BFD) to allow the use of any cryptographic authentication
algorithm in addition to the already documented authentication
schemes, described in the base specification.
Although this document has been written specifically to introduce two
new Authentication types it describes how BFD can use Hashed Message
Authentication Code (HMAC) construct along with the Secure Hash
algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions
to authenticate the control packets.
The method described in this document is generic and can be used to
extend BFD to support any cryptographic hash function in the future.
"Using SCTP as a Transport Layer Protocol for HTTP", Preethi Natarajan, Paul
Amer, Jonathan Leighton, Fred Baker, 18-Nov-08,
<draft-natarajan-http-over-sctp-00.txt>
Hyper-Text Transfer Protocol (HTTP) [RFC2116] requires a reliable
transport for end-to-end communication. While historically TCP has
been used for this purpose, this document proposes an alternative --
the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar
to TCP, SCTP offers a reliable end-to-end transport connection to
applications. Additionally, SCTP offers other innovative services
unavailable in TCP. The objectives of this draft are three-fold: (i)
to highlight SCTP services that better match HTTP's needs than TCP,
(ii) to propose a design for persistent and pipelined HTTP 1.1
transactions over SCTP's multistreaming service, and (iii) to share
some lessons learned from implementing HTTP over SCTP. Finally, open
issues warranting more discussion and/or investigation are listed.
"CRAM-MD5 to historic", Kurt Zeilenga, 18-Nov-08,
<draft-zeilenga-sasl-crammd5-00.txt>
This document recommends the retirement of the CRAM-MD5 authentication
mechanism, and discusses the reasons for doing so. This document
recommends RFC 2195 and its predecessor, RFC 2095, be moved to
Historic status.
"Ethernet MAC Destination Address for Multicast MPLS", Thomas Morin, Wim
Henderickx, Praveen Muley, Satyam Sinha, 18-Nov-08,
<draft-morin-mpls-mcast-ethernet-00.txt>
This document identifies a set of required clarifications to make it
explicit what Ethernet MAC destination address is to be used for
multicast MPLS packets, and intends to provide an update to RFC5332.
"Applicability of NAT-PMP with Service Provider Deployments of Network
Address Translation", James Woodyatt, 19-Nov-08,
<draft-woodyatt-spnatpmp-appl-01.txt>
In an effort to conserve global scope IPv4 address allocations,
service providers are deploying network address/port translators in
their interior routing domain and assigning private addresses to
residential and small office subscriber sites. This document
discusses the applicability of NAT-PMP is such networks to support
application requiring dynamic TCP and UDP port forwarding.
"vCard XML Schema", Simon Perreault, 18-Nov-08,
<draft-perreault-vcarddav-vcardxml-00.txt>
This document defines the XML schema of the vCard data format.
"A Session Identifier for the Session Initiation Protocol (SIP)", Hadriel
Kaplan, 18-Nov-08, <draft-kaplan-sip-session-id-00.txt>
There are several reasons for having a globally unique session
identifier for the same SIP session, which can be maintained across
B2BUA's and other SIP middle-boxes. This draft proposes a new SIP
header to carry such a value: Session-ID.
Kaplan
Expires May 18, 2009
[page 1]
SIP Session Identifier
November 2008
"Oxum: Octet Stream Sum
http://www.ietf.org/internet-drafts/draft-kunze-oxum-00.txt", John Kunze,
18-Nov-08, <draft-kunze-oxum-00.txt>
This document specifies "oxum", a two-part number, OCTETS.STREAMS,
that is a kind of simple size summary for complex digital objects.
In the mainstream case of a complex object that is a set of files,
the STREAMS part is the total number of files and the OCTETS part is
the total number of 8-bit bytes across all those files; for example,
an oxum of 876543.21 could mean a total of 876,543 bytes across 21
files. Which set of streams comprises a complex object for an oxum
computation depends in general on the object's type. One important
type is the stream set defined by the set of files contained in a
file hierarchy. An oxum is not a checksum in that, while a changed
oxum means a changed object, an unchanged oxum does not mean an
unchanged object.1. The size of a digital object
It can be hard to characterize the size of an arbitrary digital
object. Word count, page count, image dimensions, video running
time, or number of database records might all be useful metrics,
depending on the type of the object. For a single file, one crude
but easily obtained metric is the number of octets (8-bit bytes) in
the file. This document introduces an analogous metric for a
_complex digital object_, by which we mean an object that is not
equivalent to a single file. A complex object may consist of a group
of files or parts of one or more files (e.g., a database).2. The octet stream
sum (oxum)
A complex digital object that has a well-defined set of octet
streams, such as a document represented by a group of 14 text and
image files, has a well-defined "oxum" (octet stream sum). The oxum
is a two part number such as
567898.14
which corresponds to 567,898 octets spread over 14 files. The
general form of an oxum is
OCTETS.STREAMS
where STREAMS is the total number of streams (e.g., files) and OCTETS
is the total number of octets across all those streams. In general,
these two numbers will be positive integers, although there may be
situations (not described here) in which it makes sense for either
one of them to be left unspecified with a hyphen ('-'). The period
('.') separator is required. Other examples:
1998.10
# 1998 octets spread over 10 streams
105.3
# 105 octets, 3 streams (not 105 and 3 tenths)
21436794142.831
# almost 19 Gigabytes spread over 831 streams
709895249489.8756
# about 661 Gb, or 710 Gb if you divide by 1000
-.1
# one stream, but number of octets not known yet
The oxum is designed to be machine readable and to fit into a variety
of syntactic contexts, such as command lines, file paths, URL
[RFC3986] query strings, and XML [XML] tags.
Note that the oxum is _not_ designed as a secure digest or checksum.
While an oxum cannot change without a change to the object, an
unchanged oxum absolutely does not imply an unchanged object. Do not
use oxum in place of a cryptographic digest algorithm (cf. SHA1
[RFC3174]).3. Oxum complex object types
An _oxum object type_ is used to describe how to derive an object's
stream set. For oxum to be meaningful for an object type, the type
must have a well-defined, canonical stream set. Once the stream set
is known, the oxum computation is straightforward and the streams can
be processed in any order. One especially natural way to derive a
stream set is to define a way to reduce an object type to a file
group.
Files are primal streams. In this document, a "regular" file is a
contiguous sequence of octets with a well-defined start and end,
whether the sequence is named in static storage (e.g., "memo.pdf") or
is unnamed and recently retrieved (e.g., a web page) from a network
socket. There are many filesystem entities that are not regular
files, including directory nodes, block special files, and symbolic
links. In this document, the word "file" usually refers to a regular
file.
A (regular) file is an oxum-ready stream. As a base case, a complex
object consisting of exactly one file has an oxum of the form
"OCTETS.1", as in
12345.1
Things get more interesting when dealing with more than one file.
Any private or public agreement can be made about what constitutes a
file group, hence a stream set, for the purposes of an oxum
computation. A stream set might be declared to comprise all the
attachments of an email message, or all the files resulting from a
normalized dump procedure run against the tables of a database. An
easily delineated group is all the files contained in a directory.
Any recognized group of regular files can form on oxum stream set,
including a simple manifest or list of filenames. For example, a
transfer protocol might use oxum to help set the receiver's
expectations in terms of total bytes and files contained in a
transferred package [GRABIT].
"P4P: Provider Portal for P2P Applications", Richard Alimi, Doug Pasko, Laird
Popkin, Ye Wang, Yang Yang, 18-Nov-08, <draft-p4p-framework-00.txt>
P4P is a framework that enables Internet Service Providers (ISPs) and
network application software distributors to work jointly and
cooperatively to optimize application communications. The goals of
this cooperation are to reduce network resource consumption and to
accelerate network applications. In this document, we specify how
P4P allows ISPs to provide network guidance to applications, allowing
clients to exchange data more effectively. The applications we focus
on are those that can have a choice in connection patterns, in
particular peer-to-peer (P2P) applications.
"Single PCN Threshold Marking by using PCN baseline encoding for both
admission and termination controls", Daisuke Satoh, Mika Ishizuka, Oratai
Phanachet, Yukari Maeda, 19-Nov-08, <draft-satoh-pcn-st-marking-00.txt>
This document proposes an algorithm for marking and metering by using
pre-congestion notification (PCN) baseline encoding for both flow
admission and flow termination. The proposed algorithm uses
threshold marking whose TBthreshold.threshold is set to the number of
bits of a metered-packet smaller than the token bucket size. Another
threshold for the token bucket is required to change the marking.
frequency. Under the flow termination state, all the packets are to
be threshold-marked. Under the admission stop state, 1/Nth of
packets are to be threshold-marked when the meter indicates. We
evaluates the performance of the proposed algorithm by simulations.
Our simulation indicates that the performance is almost the same as
that of the CL[I-D.briscoe-tsvwg-cl-architecture] algorithm.
"LDAP Dereference Control", Pierangelo Masarati, Howard Chu, 19-Nov-08,
<draft-masarati-ldap-deref-00.txt>
This document describes the Dereference Control for LDAP. This
control is intended to provide a concise means to collect extra
information related to cross-links present in entries returned as
part of search responses.
"LDAP "What Failed?" Control", Pierangelo Masarati, 19-Nov-08,
<draft-masarati-ldap-whatfailed-00.txt>
This document describes the LDAP "What Failed?" control. This
control allows DUAs to request, in response to a failed operation
request, the object identifier of those extensions that caused the
operation to fail.
"Usage Agnostic Overlay Operation in RELOAD", Vidya Narayanan, 20-Nov-08,
<draft-vidya-p2psip-usage-agnostic-reload-01.txt>
RELOAD [1] defines an overlay framework for providing peer-to-peer
connectivity and storage/retreival primitives for applications.
Applications or usages are expected to reside on top of such an
overlay. In general, this is a good design that allows multiple
applications to use the same overlay framework. In such a design,
however, there are some decisions to be made in terms of what is an
overlay function and what must be defined by a usage. These
decisions should generally be based on whether the particular
function is expecting an operation or guarantee from the overlay
nodes in general or from a particular usage only. This type of
separation is especially crucial to avoid needing flag days for
upgrading nodes in order to accommodate a newer usage version for
performing the overlay operation.
"UDP Convergence Layers for the DTN Bundle and LTP Protocols", Hans Kruse,
Shawn Ostermann, 19-Nov-08, <draft-irtf-dtnrg-udp-clayer-00.txt>
This document specifies the use of the User Datagram Protocol (UDP)
as a method for transporting DTN protocol data over the Internet.
The specification covers both the use of UDP as a convergence layer
for the Bundle Protocol as well as the use of UDP to carry LTP
segments.
"Destination-Driven On-Demand Multicast Routing Protocol", Ke Tian, Jian Ma,
19-Nov-08, <draft-ke-dodmrp-00.txt>
Our protocol embeds a destination-driven feature into the on-demand
multicast structure building process of an existing multicast
protocol ODMRP (On-Demand Multicast Routing Protocol), which is a
mesh-based multicast scheme and uses a forwarding group concept. The
design objective of destination-driven on-demand multicast routing
protocol (D-ODMRP) is to improve the multicast forwarding efficiency
for wireless Ad Hoc networks. To achieve this goal, the path to
reach a multicast destination is biased towards those paths passing
through another multicast destination.
"A SIP Event Package for Subscribing to Changes to an HTTP Resource", Adam
Roach, 20-Nov-08, <draft-roach-sip-http-subscribe-00.txt>
The Session Initiation Protocol (SIP) is increasingly being used in
systems that are tightly coupled with Hypertext Transport Protocol
(HTTP) servers for a variety of reasons. In many of these cases,
applications can benefit from being able to discover, in near-real-
time, when a specific HTTP resource is created, changed, or deleted.
This document proposes a mechanism, based on the SIP events
framework, for doing so.
This document further proposes that the HTTP work necessary to make
such a mechanism work be extensible to support protocols other than
SIP for monitoring HTTP resources.
"Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions
for TCP Allocations", Marc Petit-Huguenin, 20-Nov-08,
<draft-petithuguenin-turn-tcp-variant-00.txt>
This document proposes an alternative to the Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations
[I-D.ietf-behave-turn-tcp] document.
"draft-somogyi-sdp-amr-bicc-like-00", Gabor Somogyi, 21-Nov-08,
<draft-somogyi-sdp-amr-bicc-like-00.txt>
This document describes and update to File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB)
Audio Codecs. The new format allows better interworking with widely
deployed mobile telecommunication switching systems. This document
updates RFC 4867 [RFC4867].
Next Steps in Signaling (nsis)
------------------------------
"NSLP for Quality-of-Service Signaling", Jukka Manner, Georgios Karagiannis,
Andrew McDonald, 7-Feb-08, <draft-ietf-nsis-qos-nslp-16.txt>
This specification describes the NSIS Signaling Layer Protocol (NSLP)
for signaling QoS reservations in the Internet. It is in accordance
with the framework and requirements developed in NSIS. Together with
GIST, it provides functionality similar to RSVP and extends it. The
QoS NSLP is independent of the underlying QoS specification or
architecture and provides support for different reservation models.
It is simplified by the elimination of support for multicast flows.
This specification explains the overall protocol approach, design
decisions made and provides examples. It specifies object, message
formats and processing rules.
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling,
Hannes Tschofenig, Cedric Aoun, Elwyn Davies, 3-Nov-08,
<draft-ietf-nsis-nslp-natfw-20.txt>
This memo defines the NSIS Signaling Layer Protocol (NSLP) for
Network Address Translators (NATs) and firewalls. This NSLP allows
hosts to signal on the data path for NATs and firewalls to be
configured according to the needs of the application data flows. For
instance, it enables hosts behind NATs to obtain a public reachable
address and hosts behind firewalls to receive data traffic. The
overall architecture is given by the framework and requirements
defined by the Next Steps in Signaling (NSIS) working group. The
network scenarios, the protocol itself, and examples for path-coupled
signaling are given in this memo.
"GIST: General Internet Signalling Transport", Henning Schulzrinne, Robert
Hancock, 31-Oct-08, <draft-ietf-nsis-ntlp-17.txt>
This document specifies protocol stacks for the routing and transport
of per-flow signalling messages along the path taken by that flow
through the network. The design uses existing transport and security
protocols under a common messaging layer, the General Internet
Signalling Transport (GIST), which provides a common service for
diverse signalling applications. GIST does not handle signalling
application state itself, but manages its own internal state and the
configuration of the underlying transport and security protocols to
enable the transfer of messages in both directions along the flow
path. The combination of GIST and the lower layer transport and
security protocols provides a solution for the base protocol
component of the "Next Steps in Signalling" framework.
"Applicability Statement of NSIS Protocols in Mobile Environments", Takako
Sanda, Xiaoming Fu, Seong-Ho Jeong, Jukka Manner, Hannes Tschofenig,
18-Nov-08, <draft-ietf-nsis-applicability-mobility-signaling-11.txt>
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 draft discusses the effects mobility can cause to
the NSIS protocol suite, and how the protocols operate in different
scenarios, with mobility management protocols.
"RMD-QOSM - The Resource Management in Diffserv QOS Model", Attila Bader,
7-Jul-08, <draft-ietf-nsis-rmd-13.txt>
This document describes an NSIS QoS Model for networks that use the
Resource Management in Diffserv (RMD) concept. RMD is a technique
for adding admission control and pre-emption function to
Differentiated Services (Diffserv) networks. The RMD QoS Model
allows devices external to the RMD network to signal reservation
requests to edge nodes in the RMD network. The RMD Ingress edge nodes
classify the incoming flows into traffic classes and signals resource
requests for the corresponding traffic class along the data path to
the Egress edge nodes for each flow. Egress nodes reconstitute the
original requests and continue forwarding them along the data path
towards the final destination. In addition, RMD defines notification
functions to indicate overload situations within the domain to the
edge nodes.
"GIST State Machine", Tseno Tsenov, Hannes Tschofenig, Xiaoming Fu, Cedric
Aoun, Elwyn Davies, Intellectual Property, 3-Nov-08,
<draft-ietf-nsis-ntlp-statemachine-06.txt,.pdf>
This document describes the state machines for the General Internet
Signaling Transport (GIST). The states of GIST nodes for a given flow
and their transitions are presented in order to illustrate how GIST
may be implemented.
"Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes",
Gerald Ash, Al Morton, Martin Dolly, Percy Tarapore, Chuck Dvorak, Yacine
Mghazli, 27-Oct-08, <draft-ietf-nsis-y1541-qosm-07.txt>
This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T
Recommendation Y.1541 Network QoS Classes and related signaling
requirements. Y.1541 specifies 8 classes of Network Performance
objectives, and the Y.1541-QOSM extensions include additional QSPEC
parameters and QOSM processing guidelines.
"NSIS Operation Over IP Tunnels", Charles Shen, Henning Schulzrinne,
Sung-Hyuck Lee, Jong Bang, 3-Nov-08, <draft-ietf-nsis-tunnel-05.txt>
This draft presents an NSIS operation over IP tunnel scheme using QoS
NSLP as the NSIS signaling application. Both sender-initiated and
receiver-initiated NSIS signaling modes are discussed. The scheme
creates individual or aggregate tunnel sessions for end-to-end
sessions traversing the tunnel. Packets belonging to qualified end-
to-end sessions are mapped to corresponding tunnel sessions and
assigned special flow IDs to be distinguished from the rest of the
tunnel traffic. Tunnel endpoints keep the association of the end-to-
end and tunnel session mapping, so that adjustment in one session can
be reflected in the other.
"General Internet Signaling Transport (GIST) over SCTP", Xiaoming Fu,
Christian Dickmann, Jon Crowcroft, 26-Oct-08,
<draft-ietf-nsis-ntlp-sctp-05.txt>
The General Internet Signaling Transport (GIST) protocol currently
uses TCP or TLS over TCP for connection mode operation. This
document describes the usage of GIST over the Stream Control
Transmission Protocol (SCTP). The use of SCTP can take advantage of
features provided by SCTP, namely streaming-based transport, support
of multiple streams to avoid head of line blocking, the support of
multi-homing to provide network level fault tolerance, as well as
partial reliability extension for partially reliable data
transmission. Additionally, the support for datagram TLS is also
discussed.
Network Time Protocol (ntp)
---------------------------
"Network Time Protocol Version 4 Protocol And Algorithms Specification", Jack
Burbank, 5-Sep-08, <draft-ietf-ntp-ntpv4-proto-11.txt>
The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
described in RFC 1305, as well as previous versions of the protocol.
NTPv4 includes a modified protocol header to accommodate the Internet
Protocol Version 6 address family. NTPv4 includes fundamental
improvements in the mitigation and discipline algorithms which extend
the potential accuracy to the tens of microseconds with modern workstations
and fast LANs. It includes a dynamic server discovery scheme, so that in
many cases specific server configuration is not required. It corrects certain
errors in the NTPv3 design and implementation and includes an optional extension
mechanism.
"Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)",
Heiko Gerstung, Chris Elliott, 28-Aug-08, <draft-ietf-ntp-ntpv4-mib-05.txt>
The Network Time Protocol (NTP) is used in networks of all types and
sizes for time synchronization of servers, workstations and other
networked equipment. As time synchronization is more and more a
mission critical service, standardized means for monitoring and
management of this subsystem of a networked host are required to
allow operators of such a service to setup a monitoring system that
is platform- and vendor-independant. This Internet draft provides a
standardized collection of data objects for monitoring the NTP entity
of such a network participant and it is part of the NTP Version 4
standardization effort.
"Network Time Protocol Version 4 Autokey Specification", Brian Haberman,
David Mills, 18-Aug-08, <draft-ietf-ntp-autokey-04.txt>
This memo describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public
key cryptography. Its design is based on the premise that IPSEC
schemes cannot be adopted intact, since that would preclude stateless
servers and severely compromise timekeeping accuracy. In addition,
PKI schemes presume authenticated time values are always available to
enforce certificate lifetimes; however, cryptographically verified
timestamps require interaction between the timekeeping and
authentication functions.
This memo includes the Autokey requirements analysis, design
principles and protocol specification. A detailed description of the
protocol states, events and transition functions is included. A
prototype of the Autokey design based on this memo has been
implemented, tested and documented in the NTP Version 4 (NTPv4)
software distribution for Unix, Windows and VMS at
http://www.ntp.org.
"Network Time Protocol (NTP) Server Option for DHCPv6", Richard Gayraud,
Benoit Lourdelet, 11-Jul-08, <draft-ietf-ntp-dhcpv6-ntp-opt-02.txt>
The NTP Server Option for DHCPv6 provides NTP (Network Time Protocol
version 4) configuration information to DHCPv6 hosts.
An Open Specification for Pretty Good Privacy (openpgp)
-------------------------------------------------------
"The Camellia Cipher in OpenPGP", David Shaw, 25-Apr-08,
<draft-ietf-openpgp-camellia-03.txt>
This document presents the necessary information to use the Camellia
symmetric block cipher in the OpenPGP protocol.
Operations and Management Area Working Group (opsawg)
-----------------------------------------------------
"Guidelines for Considering Operations and Management of New Protocols",
David Harrington, 27-Oct-08,
<draft-ietf-opsawg-operations-and-management-05.txt>
New protocols or protocol extensions are best designed with due
consideration of functionality needed to operate and manage the
protocol. Retrofitting operations and management is sub-optimal.
The purpose of this document is to provide guidance to authors and
reviewers of documents defining new protocols or protocol extensions,
about covering aspects of operations and management that should be
considered.
"Expressing SNMP SMI Datatypes in XML Schema Definition Language", Bob
Natale, 28-Oct-08, <draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt>
This memo (when approved as a standards-track RFC) defines the IETF
standard expression of Structure of Management Information (SMI) base
datatypes in Extensible Markup Language (XML) Schema Definition (XSD)
language. The primary objective of this memo is to enable the
production of XML documents that are as faithful to the SMI as
possible, using XSD as the validation mechanism.
"Alarms in SYSLOG", Sharon Chisholm, Rainer Gerhards, 2-Nov-08,
<draft-ietf-opsawg-syslog-alarm-01.txt>
This document describes how to send alarm information in syslog. It
includes the mapping of ITU perceived severities onto syslog message
fields.
Operational Security Capabilities for IP Network Infrastructure (opsec)
-----------------------------------------------------------------------
"Security Best Practices Efforts and Documents", Chris Lonvick, David Spak,
6-Jun-08, <draft-ietf-opsec-efforts-08.txt>
This document provides a snapshot of the current efforts to define or
apply security requirements in various Standards Developing
Organizations (SDO).
"Recommendations for filtering ICMP messages", Fernando Gont, Guillermo Gont,
31-Aug-08, <draft-ietf-opsec-icmp-filtering-00.txt>
This document document provides advice on the filtering of ICMPv4 and
ICMPv6 messages. Additionaly, it discusses the operational and
interoperability implications of such filtering.
"Issues with existing Cryptographic Protection Methods for Routing
Protocols", Susan Hares, Manav Bhatia, Vishwas Manral, Russ White, 21-Oct-08,
<draft-ietf-opsec-routing-protocols-crypto-issues-00.txt>
Routing protocols are designed to use cryptographic mechanisms to
authenticate data being received from a neighboring router to ensure
that it has not been modified in transit, and actually originated
from the neighboring router purporting to have originating the data.
Most of the cryptographic mechanisms defined to date rely on hash
algorithms applied to the data in the routing protocol packet, which
means the data is transported, in the clear, along with a signature
based on the data itself. These mechanisms rely on the manual
configuration of the keys used to seed, or build, these hash based
signatures. This document outlines some of the problems with manual
keying of these cryptographic algorithms.
Open Shortest Path First IGP (ospf)
-----------------------------------
"Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral,
21-Sep-07, <draft-ietf-ospf-ospfv3-mib-12.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in IPv6-based internets.
In particular, it defines objects for managing the Open Shortest Path
First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF
version 3 (OSPFv3).
Please send comments to ospf@ietf.org.
"OSPF Link-local Signaling", Alex Zinin, 22-Apr-08,
<draft-ietf-ospf-lls-05.txt>
OSPF is a link-state intra-domain routing protocol. OSPF routers
exchange information on a link using packets that follow a well-
defined fixed format. The format is not flexible enough to enable
new features which need to exchange arbitrary data. This document
describes a backward-compatible technique to perform link-local
signaling, i.e., exchange arbitrary data on a link.
"Support of address families in OSPFv3", Acee Lindem, Sina Mirtorabi, Abhay
Roy, Michael Barnes, Rahul Aggarwal, 31-Oct-08,
<draft-ietf-ospf-af-alt-07.txt>
This document describes a mechanism for supporting multiple address
families in OSPFv3 using multiple instances. It maps an address
family (AF) to an OSPFv3 instance using the Instance ID field in the
OSPFv3 packet header. This approach is fairly simple and minimizes
extensions to OSPFv3 for supporting multiple AFs.
"Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul
Aggarwal, Kireeti Kompella, 18-Nov-08, <draft-ietf-ospf-te-node-addr-05.txt>
OSPF Traffic Engineering (TE) extensions are used to advertise TE
Link State Advertisements (LSAs) containing information about TE-
enabled links. The only addresses belonging to a router that are
advertised in TE LSAs are the local addresses corresponding to TE-
enabled links, and the local address corresponding to the Router ID.
In order to allow other routers in a network to compute Multiprotocol
Label Switching (MPLS) traffic engineered Label Switched Paths (TE
LSPs) to a given router's local addresses, those addresses must also
be advertised by OSPF TE.
This document describes procedures that enhance OSPF TE to advertise
a router's local addresses.
"OSPF Version 2 MIB for Multi-Topology (MT) Routing", Namita Rawat,
18-Nov-08, <draft-ietf-ospf-mt-mib-03.txt>
This memo defines an extension to the Open Shortest Path First
version 2 Management Information Base (OSPFv2 MIB) for use with
network management protocols in the Internet community. In
particular it describes objects and lists considerations for the
management of OSPF Multi-Topology routing.
"OSPF HMAC-SHA Cryptographic Authentication", Manav Bhatia, 21-Oct-08,
<draft-ietf-ospf-hmac-sha-03.txt>
This document describes a mechanism for authenticating OSPF packets
by making use of the HMAC algorithm in conjunction with the SHA
family of cryptographic hash functions. Because of the way the hash
functions are used in HMAC construction, the collision attacks
currently known against SHA-1 do not apply.
This will be done in addition to the already documented
authentication schemes described in the base specification.
"OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, Philippe
Jacquet, Dang-Quan Nguyen, Thomas Clausen, 17-Nov-08,
<draft-ietf-ospf-manet-mpr-03.txt>
This document specifies an OSPFv3 interface type tailored for mobile
ad hoc networks. This interface type is derived from the broadcast
interface type, and denoted the "OSPFv3 MANET interface type".
"Extensions to OSPF to Support Mobile Ad Hoc Networking", Madhavi Chandra,
Abhay Roy, 21-Sep-08, <draft-ietf-ospf-manet-or-01.txt>
This document describes extensions to OSPF to support mobile ad hoc
networking. Specifically, the document specifies a mechanism for
link-local signaling, a OSPF-MANET interface, a simple technique to
reduce the size of Hello packets by only transmitting incremental
state changes, and a method for optimized flooding of routing
updates.
Chandra, Roy et al.
Expires March 2009
[page 1]
Internet-Draft
Extensions to OSPF to Support MANETs
September 2008
"MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo,
Intellectual Property, 3-Nov-08, <draft-ietf-ospf-manet-mdr-03.txt>
This document specifies an extension of OSPFv3 to support mobile ad
hoc networks (MANETs). The extension, called OSPF-MDR, is designed
as a new OSPF interface type for MANETs. OSPF-MDR is based on the
selection of a subset of MANET routers, consisting of MANET
Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected
dominating set (CDS), and the MDRs and Backup MDRs together form a
biconnected CDS for robustness. This CDS is exploited in two ways.
First, to reduce flooding overhead, an optimized flooding procedure
is used in which only (Backup) MDRs flood new link state
advertisements (LSAs) back out the receiving interface; reliable
flooding is ensured by retransmitting LSAs along adjacencies.
Second, adjacencies are formed only between (Backup) MDRs and a
subset of their neighbors, allowing for much better scaling in dense
networks. The CDS is constructed using 2-hop neighbor information
provided in a Hello protocol extension. The Hello protocol is
further optimized by allowing differential Hellos that report only
changes in neighbor states. Options are specified for originating
router-LSAs that provide full or partial topology information,
allowing overhead to be reduced by advertising less topology
information.
"Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay
Harwani, Carlos Pignataro, Danny McPherson, 14-Oct-08,
<draft-ietf-ospf-dynamic-hostname-01.txt>
Currently, there does not exist a simple and dynamic mechanism for
routers running OSPF to learn about symbolic hostnames just like for
routers running IS-IS. This document defines a new OSPF Router
Information (RI) TLV which allows the OSPF routers to flood their
hostname-to-Router ID mapping information across the OSPF network.
This mechanism is applicable to both OSPFv2 and OSPFv3.
Peer-to-Peer Session Initiation Protocol (p2psip)
-------------------------------------------------
"Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip
Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins, 7-Jul-08,
<draft-ietf-p2psip-concepts-02.txt>
This document defines concepts and terminology for use of the Session
Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar and message routing functions are
replaced by a distributed mechanism implemented using a distributed
hash table or other distributed data mechanism with similar external
properties. This document includes a high-level view of the
functional relationships between the network elements defined herein,
a conceptual model of operations, and an outline of the related open
problems being addressed by the P2PSIP working group. As this
document matures, it is expected to define the general framework for
P2PSIP.
"REsource LOcation And Discovery (RELOAD)", Cullen Jennings, Bruce Lowekamp,
Eric Rescorla, Salman Baset, Henning Schulzrinne, 14-Jul-08,
<draft-ietf-p2psip-reload-00.txt>
This document 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 which do not need to route traffic or store data
for others.
"A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla,
Salman Baset, Henning Schulzrinne, 27-Oct-08, <draft-ietf-p2psip-sip-00.txt>
This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD), The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system. The SIP Usage provides
lookup service for AoRs stored in the overlay. The SIP Usage also
defines GRUUs that allow the registrations to map an AoR to a
specific node reachable through the overlay. The Attach method is
used to establish a direct connection between nodes through which SIP
messages are exchanged.
"REsource LOcation And Discovery (RELOAD) Base Protocol", Cullen Jennings,
Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 27-Oct-08,
<draft-ietf-p2psip-base-00.txt>
This document 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.
Protocol for carrying Authentication for Network Access (pana)
--------------------------------------------------------------
"PANA Enabling IPsec based Access Control", Mohan Parthasarathy, 14-Jul-05,
<draft-ietf-pana-ipsec-07.txt>
PANA (Protocol for carrying Authentication for Network Access) is a
protocol for authenticating clients to the access network using IP
based protocols. The PANA protocol authenticates the client and also
establishes a PANA security association between the PANA client and
PANA authentication agent at the end of a successful authentication.
This document discusses the details for establishing an IPsec
security association using the PANA security association for enabling
IPsec based access control.
"State Machines for Protocol for Carrying Authentication for Network Access
(PANA)", Victor Fajardo, Yoshihiro Ohba, Rafa Lopez, 22-Oct-08,
<draft-ietf-pana-statemachine-07.txt>
This document defines the conceptual state machines for the Protocol
for Carrying Authentication for Network Access (PANA). The state
machines consist of the PANA Client (PaC) state machine and the PANA
Authentication Agent (PAA) state machine. The two state machines
show how PANA can interface with the EAP state machines. The state
machines and associated model are informative only. Implementations
may achieve the same results using different methods.
"Pre-authentication Support for PANA", Yoshihiro Ohba, 24-Oct-08,
<draft-ietf-pana-preauth-03.txt>
This document defines an extension to the Protocol for carrying
Authentication for Network Access (PANA) for proactively establishing
a PANA SA (Security Association) between a PaC in one access network
and a PAA in another access network to which the PaC may move. The
proposed method operates across multiple administrative domains.
"Application of PANA framework to DSL networks", Lionel Moreland, Alper
Yegin, Yoshihiro Ohba, John Kaippallimalil, 4-Nov-08,
<draft-ietf-pana-panaoverdsl-00.txt>
This document provides guidelines for PANA deployment over DSL access
networks. The document specifically describes the introduction of
PANA in DSL networks migrating from a traditional PPP access model to
a pure IP-based access environment.
Path Computation Element (pce)
------------------------------
"Path Computation Element (PCE) Communication Protocol (PCEP)", Arthi
Ayyangar, Adrian Farrel, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi
Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux, 19-Nov-08,
<draft-ietf-pce-pcep-19.txt>
This document specifies the Path Computation Element Communication
Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs.
Such interactions include path computation requests and path
computation replies as well as notifications of specific states
related to the use of a PCE in the context of Multiprotocol Label
Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP
is designed to be flexible and extensible so as to easily allow for
the addition of further messages and objects, should further
requirements be expressed in the future.
"PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic
Engineering", Eiji Oki, Jean-Louis Le Roux, Kenji Kumaki, Adrian Farrel,
Tomonori Takeda, 15-Oct-08, <draft-ietf-pce-inter-layer-req-08.txt>
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in Multi-Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered client/server
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network
layers. PCE is a candidate solution for such requirements.
Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in "PCE
Communication Protocol Generic Requirements". Generic requirements
for PCE discovery protocol are presented in "Requirements for Path
Computation Element (PCE) Discovery".
This document complements the generic requirements and presents
detailed sets of PCC-PCE communication protocol requirements and PCE
discovery protocol requirements for inter-layer traffic engineering.
"Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering",
Tomonori Takeda, Jean-Louis Le Roux, Adrian Farrel, Eiji Oki, 24-Jul-08,
<draft-ietf-pce-inter-layer-frwk-07.txt>
A network may comprise multiple layers. It is important to globally
optimize network resource utilization, taking into account all
layers, rather than optimizing resource utilization at each layer
independently. This allows better network efficiency to be achieved
through a process that we call inter-layer traffic engineering. The
Path Computation Element (PCE) can be a powerful tool to achieve
inter-layer traffic engineering.
This document describes a framework for applying the PCE-based
architecture to inter-layer Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) traffic engineering. It provides
suggestions for the deployment of PCE in support of multi-layer
networks. This document also describes network models where PCE
performs inter-layer traffic engineering, and the relationship
between PCE and a functional component called the Virtual Network
Topology Manager (VNTM).
"Policy-Enabled Path Computation Framework", Igor Bryskin, Dimitri
Papadimitriou, Lou Berger, Gerald Ash, 31-Oct-08,
<draft-ietf-pce-policy-enabled-path-comp-04.txt>
The Path Computation Element (PCE) Architecture introduces the
concept of policy in the context of path computation. This document
provides additional details on policy within the PCE Architecture and
also provides context for the support of PCE Policy. This document
introduces the use of the Policy Core Information Model (PCIM) as a
framework for supporting path computation policy. This document also
provides representative scenarios for the support of PCE Policy.
"A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute
Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths",
JP Vasseur, Raymond Zhang, Nabil Bitar, Jean-Louis Roux, 14-Apr-08,
<draft-ietf-pce-brpc-09.txt>
The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains (where a
domain is a collection of network elements within a common sphere of
address management or path computational responsibility such as an
IGP area or an Autonomous Systems) has been identified as a key
requirement. This document specifies a procedure relying on the use
of multiple Path Computation Elements (PCEs) to compute such inter-
domain shortest constrained paths across a predetermined sequence of
domains, using a backward recursive path computation technique. This
technique preserves confidentiality across domains, which is
sometimes required when domains are managed by different Service
Providers.
"Definitions of Managed Objects for Path Computation Element Discovery",
Emile Stephan, 24-Oct-08, <draft-ietf-pce-disc-mib-03.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing Path
Computation Elements Discovery.
"Definitions of Textual Conventions for Path Computation Element", Emile
Stephan, 1-Jul-08, <draft-ietf-pce-tc-mib-03.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines Textual Conventions to represent commonly
used Path Computation Element (PCE) management information. The
intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and
used in PCE related MIB modules to avoid duplicating conventions.
"Inclusion of Manageability Sections in PCE Working Group Drafts", Adrian
Farrel, 15-Oct-08, <draft-ietf-pce-manageability-requirements-05.txt>
It has often been the case that manageability considerations have
been retrofitted to protocols after they have been specified,
standardized, implemented, or deployed. This is sub-optimal.
Similarly, new protocols or protocol extensions are frequently
designed without due consideration of manageability requirements.
This document specifies the recommendation for all new
Internet-Drafts in the PCE Working Group to include a
"Manageability Considerations" section, and gives guidance on what
that section should contain.
"Extensions to the Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", Tomonori Takeda, Eiji Oki, Adrian Farrel, 18-Jul-08,
<draft-ietf-pce-pcep-xro-06.txt>
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it
may be useful for the PCC to specify, as constraints to the path
computation, abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from the computed route.
Such constraints are termed route exclusions.
The PCE Communication Protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs. This document presents PCEP
extensions for route exclusions.
"Preserving Topology Confidentiality in Inter-Domain Path Computation Using a
Key-Based Mechanism", Richard Bradford, JP Vasseur, Adrian Farrel, 17-Nov-08,
<draft-ietf-pce-path-key-05.txt>
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering (TE) Label Switched Paths (LSPs) may be
computed by Path Computation Elements (PCEs). Where the TE LSP
crosses multiple domains, such as Autonomous Systems (ASes), the
path may be computed by multiple PCEs that cooperate, with each
responsible for computing a segment of the path. However, in some
cases (e.g., when ASes are administered by separate Service
Providers), it would break confidentiality rules for a PCE to
supply a path segment to a PCE in another domain, thus disclosing
AS-internal topology information. This issue may be circumvented
by returning a loose hop and by invoking a new path computation
from the domain boundary Label Switching Router (LSR) during TE
LSP setup as the signaling message enters the second domain, but
this technique has several issues including the problem of
maintaining path diversity.
Bradford, Vasseur and Farrel
[page 1]
draft-ietf-pce-path-key-05.txt
November 2008
This document defines a mechanism to hide the contents of a
segment of a path, called the Confidential Path Segment (CPS). The
CPS may be replaced by a path-key that can be conveyed in the PCE
Communication Protocol (PCEP) and signaled within in a Resource
Reservation Protocol TE (RSVP-TE) explicit route object.
"Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization", Young Lee,
Jean-Louis Le Roux, Daniel King, Eiji Oki, 23-Oct-08,
<draft-ietf-pce-global-concurrent-optimization-05.txt>
The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the
network. In this context a PCC may be a Label Switching Router
(LSR), a Network Management System (NMS), or another PCE. The Path
Computation Element Communication Protocol (PCEP) is specified for
communications between PCCs and PCEs, and between cooperating PCEs.
When computing or re-optimizing the routes of a set of TE LSPs
through a network it may be advantageous to perform bulk path
computations in order to avoid blocking problems and to achieve more
optimal network-wide solutions. Such bulk optimization is termed
Global Concurrent Optimization (GCO). A GCO is able to
simultaneously consider the entire topology of the network and the
complete set of existing TE LSPs, and their respective constraints,
and look to optimize or re-optimize the entire network to satisfy all
constraints for all TE LSPs. A GCO may also be applied to some
subset of the TE LSPs in a network. The GCO application is primarily
a Network Management System (NMS) solution.
While GCO is applicable to any simultaneous request for multiple TE
LSPs (for example, a request for end-to-end protection), it is not
envisaged that global concurrent reoptimization would be applied in a
network (such as an MPLS-TE network) that contains a very large
number of very low bandwidth or zero bandwidth TE LSPs since the
large scope of the problem and the small benefit of concurrent
reoptimization relative to single TE LSP reoptimization is unlikely
to make the process worthwhile. Further, applying global concurrent
reoptimization in a network with a high rate of change of TE LSPs
(churn) is not advised because of the likelihood that TE LSPs would
change before they could be globally reoptimized. Global
reoptimization is more applicable to stable networks such as
transport networks or those with long-term TE LSP tunnels.
This document provides application-specific requirements and the PCEP
extensions in support of GCO applications.
"Encoding of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", Jean-Louis Le Roux, JP Vasseur, Young Lee,
6-Sep-08, <draft-ietf-pce-of-05.txt>
The computation of one or a set of Traffic Engineering Label Switched
Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks, is subject to a set of one or more
specific optimization criteria, referred to as objective functions
(e.g. minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a path to be computed for one or
more TE LSPs according to a specific objective function. Thus, the
PCC needs to instruct the PCE to use the correct objective function.
Furthermore, it is possible that not all PCEs support the same set of
objective functions, therefore it is useful for the PCC to be able to
automatically discover the set of objective functions supported by
each PCE.
This document defines extensions to the PCE communication Protocol
(PCEP) to allow a PCE to indicate the set of objective functions it
supports. Extensions are also defined so that a PCC can indicate in
a path computation request the required objective function, and so
that a PCE can report in a path computation reply the objective
function that was used for path computation.
"A set of monitoring tools for Path Computation Element based Architecture",
JP Vasseur, Jean-Louis Le Roux, Yuichi Ikejiri, 3-Nov-08,
<draft-ietf-pce-monitoring-03.txt>
A Path Computation Element (PCE) based architecture has been
specified for the computation of Traffic Engineering (TE) Label
Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks in the context of single or
multiple domains (where a domain refers to a collection of network
elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems). In PCE-based environments, it is thus critical to monitor
the state of the path computation chain for troubleshooting and
performance monitoring purposes: liveness of each element (PCE)
involved in the PCE chain, detection of potential resource contention
states and statistics in term of path computation times are examples
of such metrics of interest. This document specifies procedures and
extensions to the Path Computation Element Protocol (PCEP) in order
to gather such information.
"Diff-Serv Aware Class Type Object for Path Computation Element Communication
Protocol", Siva Sivabalan, Jon Parker, Sami Boutros, 3-Nov-08,
<draft-ietf-pce-dste-02.txt>
This document specifies a CLASSTYPE object to support Diff-Serve
Aware Traffic Engineering (DS-TE) where path computation is performed
with an aid of Path Computation Element (PCE).
"Extensions to the Path Computation Element communication Protocol (PCEP) for
Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Jean-Louis Le
Roux, Adrian Farrel, 30-Jun-08, <draft-ietf-pce-inter-layer-ext-01.txt>
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.
MPLS and GMPLS networks may be constructed from layered service
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network
layers through a process called inter-layer traffic engineering.
PCE is a candidate solution for such requirements.
The PCE communication Protocol (PCEP) is designed as a
communication protocol between Path Computation Clients (PCCs) and
PCEs. This document presents PCEP extensions for inter-layer
traffic engineering.
"draft-ietf-pce-p2mp-app-00.txt", Seisho Yasukawa, Adrian Farrel, 8-Aug-08,
<draft-ietf-pce-p2mp-app-00.txt>
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs).
This document examines the applicability of PCE to path computation
for P2MP TE LSPs in MPLS and GMPLS networks. It describes the
motivation for using a PCE to compute these paths, and examines which
of the PCE architectural models are appropriate.
"PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol
Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian
Farrel, 8-Aug-08, <draft-ietf-pce-p2mp-req-00.txt>
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.
Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
already established, and since P2MP TE LSP routes are sometimes
complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in "Path
Computation Element (PCE) Communication Protocol Generic
Requirements". This document complements the generic requirements and
presents a detailed set of PCC-PCE communication protocol
requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
"Extensions to the Path Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Paths", Quintin Zhao,
Daniel King, Fabien Verhaeghe, Tomonori Takeda, Mohamad Chaitou, Jean-Louis
Le Roux, Zafar Ali, 3-Nov-08, <draft-ietf-pce-pcep-p2mp-extensions-01.txt>
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established
using signaling techniques, but their paths may first be determined. The
Path Computation Element (PCE) has been identified as an appropriate technology
for the determination of the paths of P2MP TE LSPs.
This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs.
"Requirements for GMPLS applications of PCE", Tomohiro Otani, Kenichi Ogaki,
Diego Caviglia, 17-Sep-08, <draft-ietf-pce-gmpls-aps-req-00.txt>
The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element).
"The use of SVEC (Synchronization VECtor) list for Synchronized dependent
path computations", Itaru Nishioka, Daniel King, 29-Sep-08,
<draft-ietf-pce-pcep-svec-list-00.txt>
A Path Computation Element (PCE) performing dependent path
computations, for instance calculating a diverse working and
protected path do not share common network points, would need to
synchronize the computations in order to increase the probability
of meeting the working and protected path disjoint objective and
network resource optimization objective. When a PCE computes
multiple sets of dependent path computation requests concurrently,
it is required to use Synchronization VECtor (SVEC) list for
association among the sets of dependent path computation requests.
This document describes the usage of multiple SVECs in the SVEC
list and its processing guideline, for the synchronized computation
of dependent paths.
Congestion and Pre-Congestion Notification (pcn)
------------------------------------------------
"Pre-Congestion Notification (PCN) Architecture", Philip Eardley, 20-Oct-08,
<draft-ietf-pcn-architecture-08.txt>
This document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect
the quality of service of established inelastic flows within a single
DiffServ domain.Status
"Baseline Encoding and Transport of Pre-Congestion Information", T Moncaster,
Bob Briscoe, Michael Menth, 14-Oct-08,
<draft-ietf-pcn-baseline-encoding-01.txt>
Pre-congestion notification (PCN) provides information to support
admission control and flow termination in order to protect the
Quality of Service of inelastic flows. It does this by marking
packets when traffic load on a link is approaching or has exceeded a
threshold below the physical link rate. This document specifies how
such marks are to be encoded into the IP header. The baseline
encoding described here provides for only two PCN encoding states.
It is designed to be easily extended to provide more encoding states
but such schemes will be described in other documents.
"Marking behaviour of PCN-nodes", Philip Eardley, 20-Oct-08,
<draft-ietf-pcn-marking-behaviour-01.txt>
This document standardises the two marking behaviours of PCN-nodes:
threshold marking and excess traffic marking. Threshold marking
marks all PCN-packets if the PCN traffic rate is greater than its
configured rate. Excess traffic marking marks a proportion of PCN-
packets, such that the amount marked equals the traffic rate in
excess of its configured rate. Setting the configured rates below
the physical link rates enables PCN-nodes to provide information to
support admission control and flow termination in order to protect
the quality of service of established inelastic flows.
Protocol Independent Multicast (pim)
------------------------------------
"The RPF Vector TLV", IJsbrand Wijnands, 20-Oct-08,
<draft-ietf-pim-rpf-vector-06.txt>
This document describes a use of the PIM Join Attribute as defined in
draft-ietf-pim-join-attributes [I-D.ietf-pim-join-attributes] which
enables PIM to build multicast trees through an MPLS-enabled network,
even if that network's IGP does not have a route to the source of the
tree.
"Authentication and Confidentiality in PIM-SM Link-local Messages", William
Atwood, Salekul Islam, Maziar Siami, 3-Nov-08,
<draft-ietf-pim-sm-linklocal-05.txt>
RFC 4601 mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link local messages using the IP security
(IPsec) Authentication Header (AH) or Encapsulating Security Payload
(ESP). It specifies optional mechanisms to provide confidentiality
using the ESP. Manual keying is specified as the mandatory and
default group key management solution. To deal with issues of
scalability and security that exist with manual keying, an optional
automated group key management mechanism is specified.
"Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd,
28-Jul-08, <draft-ietf-pim-pop-count-00.txt>
This specification defines a method for providing multicast
distribution-tree accounting data for billing and debugging. Simple
extensions to the PIM protocol allow a rough approximation of tree-
based data in a scalable fashion.
"A Reliable Transport Mechanism for PIM", Dino Farinacci, IJsbrand Wijnands,
Apoorva Karan, A Boers, Maria Napierala, 22-Aug-08,
<draft-ietf-pim-port-00.txt>
This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol.
"PIM Group-to-RP Mapping", Bharat Joshi, Andy Kessler, David McWalter,
21-Oct-08, <draft-ietf-pim-group-rp-mapping-00.txt>
Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a 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 allow administrator to override a specific Group-
to-RP mapping with the static Group-to-RP mapping which an
administrator would want to use. This algorithm also does not
consider the PIM mode and the mechanism through which a Group-to-RP
mapping was learned.
The intention of this document is to suggest 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.
Public-Key Infrastructure (X.509) (pkix)
----------------------------------------
"Internet X.509 Public Key Infrastructure: Additional Algorithms and
Identifiers for DSA and ECDSA", Quynh Dang, 30-Oct-08,
<draft-ietf-pkix-sha2-dsa-ecdsa-05.txt>
This document supplements RFC 3279. It specifies algorithm
identifiers and ASN.1 encoding rules for the Digital
Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA) digital signatures when using
SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm.
This specification applies to the Internet X.509 Public Key
Infrastructure (PKI) when digital signatures are used to
sign certificates and certificate revocation lists (CRLs).
"Elliptic Curve Cryptography Subject Public Key Information", Sean Turner,
Kelvin Yiu, Daniel R. L. Brown, Russ Housley, William Polk, 27-Oct-08,
<draft-ietf-pkix-ecc-subpubkeyinfo-09.txt>
This document specifies the syntax and semantics for the Subject
Public Key Information field in certificates that support Elliptic
Curve Cryptography. This document updates Sections 2.3.5, 3, and 5
of RFC 3279.
"New ASN.1 Modules for PKIX", Paul Hoffman, Jim Schaad, 10-Jul-08,
<draft-ietf-pkix-new-asn1-01.txt>
The PKIX certificate format, and many associated formats, are
expressed using ASN.1. The current ASN.1 modules conform to the 1988
version of ASN.1. This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1. There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.
"Update for RSAES-OAEP Algorithm Parameters", Sean Turner, Kelvin Yiu, Daniel
R. L. Brown, Russ Housley, William Polk, 1-May-08,
<draft-ietf-pkix-rfc4055-update-01.txt>
This document updates RFC 4055. It updates the conventions for using
the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding
(RSAES-OAEP) key transport algorithm with the Public-Key Cryptography
Standards (PKCS) #1 version 1.5 signature algorithm in the Internet
X.509 Public Key Infrastructure (PKI). Specifically, it updates the
conventions for algorithm parameters in an X.509 certificate's
subjectPublicKeyInfo field.
"Traceable Anonymous Certificate", Sanghwan Park, Haeryong Park, Yoojae Won,
Jaeil Lee, Stephen Kent, 28-Oct-08, <draft-ietf-pkix-tac-01.txt>
Public Key Infrastructure (PKI) provides a powerful means of
authenticating individuals, organizations, and computers(e.g.,
web servers). However, when individuals use certificates to
access resources on the public Internet, there are legitimate
concerns about personal privacy, and thus there are increasing
demands for privacy enhancing techniques on the Internet.
In a PKI, an authorized entity such as a certification Authority
(CA) or a Registration Authority (RA) may be perceived, from a
privacy perspective, as a "big brother," even when a CA issues a
certificate containing a Subject name that is a pseudonym. This
is because such entities can always map a pseudonym in a
certificate they issued to the name of the real user to whom it
was issued. This document defines a practical architecture and
protocols for offering privacy for a user who requests and uses
an X.509 certificate containing a pseudonym, while still retaining
the ability to map such a certificate to the real user who
requested it. The architecture is compatible with IETF certificate
request formats such as PKCS10 [2], CRMF [3]. The architecture
separates the authorities involved in issuing a certificate: one
for verifying ownership of a private key (Blind Issuer) and the
other for validating the contents of a certificate (Anonymous
Issuer). The end-entity(EE) certificates issued under this model
are called Traceable Anonymous Certificates (TACs).
"Trust Anchor Management Requirements", Raksha Reddy, Carl Wallace,
30-Oct-08, <draft-ietf-pkix-ta-mgmt-reqs-02.txt>
A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.
"PKI Resource Query Protocol (PRQP)", Massimiliano Pala, 2-Jul-08,
<draft-ietf-pkix-prqp-00.txt>
One of the most strategic problems still open in PKIX is locating
public data and services associated with a Certification Authority
(CA). This issue impacts interoperability and usability in PKIX.
This draft describes the PKI Resource Query Protocol (PRQP), its
design, definition, and its impact in already deployed PKIX
protocols.
"Other Certificates Extension", Stephen Farrell, 29-Sep-08,
<draft-ietf-pkix-other-certs-01.txt>
Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information. This memo defines a certificate
extension that allows applications to establish the required linkage
without introducing a new application protocol data unit.
"Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate
Extension", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08,
<draft-ietf-pkix-cms-content-constraints-00.txt>
This document specifies the syntax and semantics for the
Cryptographic Message Syntax (CMS) content constraints X.509
certificate extension. This extension is used to determine whether
the public key in an X.509 public key certificate is appropriate to
use in the processing of a protected content. In particular, the CMS
content constraints certificate extension is one part of the
authorization decision; it is used when validating a digital
signature on a CMS SignedData content or validating a message
authentication code (MAC) on a CMS AuthenticatedData content or CMS
AuthEnvelopedData content. The signed or authenticated content type
is identified by an ASN.1 object identifier, and this certificate
extension indicates the content types that the certified public key
is authorized to validate. If the authorization check is successful,
the CMS content constraints certificate extension also provides
default values for absent attributes.
"Trust Anchor Format", Russ Housley, Sam Ashmore, Carl Wallace, 6-Oct-08,
<draft-ietf-pkix-ta-format-00.txt>
This document describes a structure for representing trust anchor
information. A trust anchor is an authoritative entity represented
via a public key and associated data. The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative. The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements and for use within the context of the
Trust Anchor Management Protocol (TAMP).
"Trust Anchor Management Protocol (TAMP)", Russ Housley, Sam Ashmore, Carl
Wallace, 6-Oct-08, <draft-ietf-pkix-tamp-00.txt>
This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store. The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication. The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.
"An Internet Attribute Certificate Profile for Authorization: Update", Russ
Housley, Stephen Farrell, Sean Turner, 27-Oct-08,
<draft-ietf-pkix-3281update-01.txt>
This document updates RFC 3281. It incorporates verified errata.
"Clearance Attribute and Authority Clearance Constraints Certificate
Extension", Santosh Chokhani, Sean Turner, 31-Oct-08,
<draft-ietf-pkix-authorityclearanceconstraints-00.txt>
This document defines the syntax and semantics for the Clearance
attribute and the Authority Clearance Constraints extension in X.509
certificates. The Clearance attribute is used to indicate the
clearance held by the subject. The Clearance attribute may appear in
the subject directory attributes extension of a public key certificate or
in the attributes field of an attribute certificate. The Authority Clearance
Constraints certificate extension values in a Trust Anchor (TA), CA public
key certificates, and an Attribute Authority (AA) public key certificate
in a public key certification path constrain the effective Clearance of the
subject.
Performance Metrics for Other Layers (pmol)
-------------------------------------------
"SIP End-to-End Performance Metrics", Daryl Malas, 1-Nov-08,
<draft-ietf-pmol-sip-perf-metrics-02.txt>
This document defines a set of metrics and their usage to evaluate
the performance of end-to-end Session Initiation Protocol (SIP) based
services in both production and testing environments. The purpose of
this document is to combine a set of common metrics, allowing
interoperable performance measurements, easing the comparison of
industry implementations.
"Framework for Performance Metric Development", Alan Clark, 2-Nov-08,
<draft-ietf-pmol-metrics-framework-01.txt>
This memo describes a framework and guidelines for the development of
performance metrics that are beyond the scope of existing working
group charters in the IETF. In this version, the memo refers to a
Performance Metrics Entity, or PM Entity, which may in future be a
working group or directorate or a combination of these two.
Packet Sampling (psamp)
-----------------------
"A Framework for Packet Selection and Reporting", Derek Chiou, Benoit Claise,
Nick Duffield, Albert Greenberg, Matthias Grossglauser, Jennifer Rexford,
Sharon Goldberg, 26-Jun-08, <draft-ietf-psamp-framework-13.txt>
This document specifies a framework for the PSAMP (Packet
SAMPling) protocol. The functions of this protocol are to select
packets from a stream according to a set of standardized
selectors, to form a stream of reports on the selected packets,
and to export the reports to a collector. This framework details
the components of this architecture, then describes some generic
requirements, motivated by the dual aims of ubiquitous deployment
and utility of the reports for applications. Detailed
requirements for selection, reporting and exporting are
described, along with configuration requirements of the PSAMP
functions.
"Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby,
10-Jul-08, <draft-ietf-psamp-sample-tech-11.txt>
This document describes Sampling and Filtering techniques for IP
packet selection. It provides a categorization of schemes and
defines what parameters are needed to describe the most common
selection schemes. Furthermore it shows how techniques can be
combined to build more elaborate packet Selectors. The document
provides the basis for the definition of information models for
configuring selection techniques in Metering Processes and for
reporting the technique in use to a Collector.
"Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 18-Dec-07,
<draft-ietf-psamp-protocol-09.txt>
This document specifies the export of packet information from a
PSAMP Exporting Process to a PSAMP Collecting Process. For export
of packet information the IP Flow Information eXport (IPFIX)
protocol is used, as both the IPFIX and PSAMP architecture match
very well and the means provided by the IPFIX protocol are
sufficient. The document specifies in detail how the IPFIX protocol
is used for PSAMP export of packet information.
"Information Model for Packet Sampling Exports", Thomas Dietz, Benoit Claise,
Paul Aitken, Falko Dressler, Georg Carle, 20-Oct-08,
<draft-ietf-psamp-info-11.txt>
This memo defines an information model for the Packet Sampling
(PSAMP) protocol. It is used by the PSAMP protocol for encoding
sampled packet data and information related to the Sampling process.
As the PSAMP protocol is based on the IPFIX protocol, this
information model is an extension to the IPFIX information model.
Pseudowire Emulation Edge to Edge (pwe3)
----------------------------------------
"Pseudowire (PW) Management Information Base (MIB)", Thomas Nadeau, David
Zelig, 9-Jan-08, <draft-ietf-pwe3-pw-mib-14.txt>
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 Pseudowire Edge-to-Edge services carried over a general
Packet Switched Network.
"Pseudowire (PW) over MPLS PSN Management Information Base (MIB)", David
Zelig, Thomas Nadeau, 9-Jan-08, <draft-ietf-pwe3-pw-mpls-mib-14.txt>
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 PW operation over Multi-
Protocol Label Switching (MPLS) Label Switch Router (LSR).
"Definitions of Textual Conventions for Pseudowires (PW) Management", Thomas
Nadeau, David Zelig, Orly Nicklass, 9-Jan-08,
<draft-ietf-pwe3-pw-tc-mib-14.txt>
This memo defines a Management Information Base (MIB) module which
contains Textual Conventions (TCs) to represent commonly-used
Pseudowire (PW) management information. The intent is that these TCs
will be imported and used in PW-related MIB modules that would
otherwise define their own representations.
"SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information
Base (MIB) Using SMIv2", David Zelig, Ron Cohen, Thomas Nadeau, 9-Jan-08,
<draft-ietf-pwe3-cep-mib-12.txt>
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 SONET/SDH
circuits over a Packet Switch Network (PSN).
"Ethernet Pseudowire (PW) Management Information Base (MIB)", David Zelig,
Thomas Nadeau, 9-Jan-08, <draft-ietf-pwe3-enet-mib-13.txt>
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 of Ethernet
Pseudowire (PW) services.
"Managed Objects for ATM over Packet Switched Network (PSN)", Orly Nicklass,
Senthilkumar Sathappan, Marichetty Venkatesan, Thomas Nadeau, 21-Oct-08,
<draft-ietf-pwe3-pw-atm-mib-06.txt>
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 ATM
Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN).
"Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass,
21-Oct-08, <draft-ietf-pwe3-tdm-mib-11.txt>
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 pseudo wire
encapsulation for structured or unstructured TDM (T1, E1, T3, E3)
circuits over a Packet Switch Network (PSN).
"Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, Monique Morrow, Luca
Martini, Carlos Pignataro, Dinesh Mohan, 3-Nov-08,
<draft-ietf-pwe3-oam-msg-map-08.txt>
This document specifies the mapping of defect states between a Pseudo
Wire and the Attachment Circuits (AC) of the end-to-end emulated
service. This document covers the case whereby the ACs and the PWs
are of the same type in accordance to the PWE3 architecture [RFC3985]
such that a homogenous PW service can be constructed.
"Segmented Pseudo Wire", Thomas Nadeau, Chris Metz, Michael Duckett, Matthew
Bocci, Florin Balus, Luca Martini, 25-Jul-08,
<draft-ietf-pwe3-segmented-pw-09.txt>
This document describes how to connect pseudowires (PW) between two
distinct PW control planes or PSN domains. The PW control planes may
belong to independent autonomous systems, or the PSN technology is
heterogeneous, or a PW might need to be aggregated at a specific PSN
point. The PW packet data units are simply switched from one PW to
another without changing the PW payload.
"Dynamic Placement of Multi Segment Pseudo Wires", Luca Martini, Matthew
Bocci, Nabil Bitar, Himanshu Shah, Mustapha Aissaoui, Florin Balus,
25-Jul-08, <draft-ietf-pwe3-dynamic-ms-pw-08.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.
"An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge",
Matthew Bocci, Stewart Bryant, 25-Sep-08, <draft-ietf-pwe3-ms-pw-arch-05.txt>
This document describes an architecture for extending pseudowire
emulation across multiple packet switched network segments. Scenarios
are discussed where each segment of a given edge-to-edge emulated
service spans a different provider's PSN, and where the emulated
service originates and terminates on the same providers PSN, but may
pass through several PSN tunnel segments in that PSN. It presents an
architectural framework for such multi-segment pseudowires, defines
"Encapsulation Methods for Transport of Fibre Channel frames Over MPLS
Networks", Moran Roth, Tel Aviv, David Zelig, Tel Aviv, San Jose, 19-Aug-08,
<draft-ietf-pwe3-fc-encap-08.txt>
A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames
over an MPLS network. This enables service providers to offer
"emulated" Fibre Channel services over existing MPLS networks. This
document specifies the encapsulation of Fibre Channel PDUs within a
pseudowire. It also specifies the procedures for using a PW to
provide a Fibre Channel service.
"Pseudowire Congestion Control Framework", Stewart Bryant, Bruce Davie, Luca
Martini, Eric Rosen, 28-May-08, <draft-ietf-pwe3-congestion-frmwk-01.txt>
Pseudowires are sometimes used to carry non-TCP data flows. In these
circumstances the service payload will not react to network
congestion by reducing its offered load. Pseudowires should
therefore reduces their network bandwidth demands in the face of
significant packet loss, including if necessary completely ceasing
transmission. Since it is difficult to determine a priori the number
of equivalent TCP flow that a pseudowire represents, a suitably
"fair" rate of back-off cannot be pre-determined. This document
describes pseudowire congestion problem and provides guidance on the
development suitable solutions.
"Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", Thomas Nadeau, Carlos Pignataro,
25-Jun-08, <draft-ietf-pwe3-vccv-bfd-02.txt>
This document describes new Connectivity Verification (CV) types
using Bidirectional Forwarding Detection (BFD) with Virtual Circuit
Connectivity Verification (VCCV). VCCV provides a control channel
that is associated with a Pseudowire (PW), as well as the
corresponding operations and management functions such as
connectivity verification to be used over that control channel.
"Preferential Forwarding Status bit definition", Praveen Muley, Matthew
Bocci, Luca Martini, 30-Sep-08, <draft-ietf-pwe3-redundancy-bit-01.txt>
This document describes a mechanism for standby status signaling of
redundant PWs between their termination points. A set of redundant
PWs is configured between PE nodes in SS-PW applications, or between
T-PE nodes in MS-PW applications.
In order for the PE/T-PE nodes to indicate the preferred PW path to
forward to one another, a new status bit is needed to indicate a
preferential forwarding status of active or standby for each PW in
the redundancy set.
In addition, a second status bit is defined to allow peer PE/T-PE
nodes to coordinate a switchover operation of the PW/MS-PW path.
"Pseudowire (PW) Redundancy", Praveen Muley, Matthew Bocci, 30-Sep-08,
<draft-ietf-pwe3-redundancy-01.txt>
This document describes a framework comprised of few scenarios and
associated requirements where PW redundancy is needed. A set of
redundant PWs is configured between PE nodes in SS-PW applications,
or between T-PE nodes in MS-PW applications. In order for the PE/T-PE
nodes to indicate the preferred PW path to forward to one another, a
new status is needed to indicate the preferential forwarding status
of active or standby for each PW in the redundancy set.
"Requirements for Point-to-Multipoint Pseudowire", Frederic JOUNAY, Philippe
Niger, Yuji Kamite, Simon DeLord, Luca Martini, 4-Sep-08,
<draft-ietf-pwe3-p2mp-pw-requirements-00.txt>
This document presents a set of requirements for providing an
unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to
Edge) emulation. The requirements identified in this document are
related to architecture, signaling and maintenance aspects of a
Point-to-Multipoint PW operation. They are proposed as guidelines for
the standardization of such mechanisms. Among other potential
applications Point-to-Multipoint PWs SHOULD be used to optimize the
support of multicast services as defined in the Layer 2 Virtual
Private Network working group.
RADIUS EXTensions (radext)
--------------------------
"Remote Authentication Dial-In User Service (RADIUS) Authorization for
Network Access Server (NAS) Management", David Nelson, Greg Weber, 10-Oct-08,
<draft-ietf-radext-management-authorization-06.txt>
This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS). Both local and remote management are supported,
with granular access rights and management privileges. Specific
provisions are made for remote management via framed management
protocols, and for management access over a secure transport
protocol.
"RADIUS Design Guidelines", Greg Weber, Alan DeKok, Intellectual Property,
26-Aug-08, <draft-ietf-radext-design-05.txt>
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).
"Extended Remote Authentication Dial In User Service (RADIUS) Attributes",
Yong Li, Avi Lior, Glen Zorn, 2-Nov-08,
<draft-ietf-radext-extended-attributes-05.txt>
For the Remote Authentication Dial In User Service (RADIUS) protocol
to continue to support new applications, the RADIUS attribute type
space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with the
existing protocol. This document defines a mechanism to accomplish
that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.
"Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)", David
Nelson, 19-Nov-08, <draft-ietf-radext-crypto-agility-requirements-01.txt>
This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).
"TLS encryption for RADIUS over TCP (RadSec)", Stefan Winter, Mike McCauley,
Stig Venaas, Klaas Wierenga, 24-Oct-08, <draft-ietf-radext-radsec-02.txt>
This document specifies security on the transport layer (TLS) for the
RADIUS protocol [RFC2865] when transmitted over TCP
[I-D.dekok-radext-tcp-transport]. This enables dynamic trust
relationships between RADIUS servers.
"Use of Status-Server Packets in the Remote Authentication Dial In User
Service (RADIUS) Protocol", Alan DeKok, 3-Nov-08,
<draft-ietf-radext-status-server-02.txt>
RFC 2865 defines a Status-Server code for use in RADIUS, but labels
it as "Experimental" without further discussion. This document
describes a practical use for the Status-Server packet code, which is
to let clients query the status of a RADIUS server. These queries,
and responses (if any) enable the client to make more informed
decisions. The result is a more stable, and more robust RADIUS
architecture.
Reliable Multicast Transport (rmt)
----------------------------------
"Layered Coding Transport (LCT) Building Block", Michael Luby, Mark Watson,
Lorenzo Vicisano, 12-Jul-08, <draft-ietf-rmt-bb-lct-revised-07.txt>
Layered Coding Transport (LCT) provides transport level support for
reliable content delivery and stream delivery protocols. LCT is
specifically designed to support protocols using IP multicast, but
also provides support to protocols that use unicast. LCT is
compatible with congestion control that provides multiple rate
delivery to receivers and is also compatible with coding techniques
that provide reliable delivery of content. This document obsoletes
RFC3451
"Asynchronous Layered Coding (ALC) Protocol Instantiation", Michael Luby,
Mark Watson, Lorenzo Vicisano, 1-Nov-08,
<draft-ietf-rmt-pi-alc-revised-06.txt>
This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport
(LCT) building block, a multiple rate congestion control building
block and the Forward Error Correction (FEC) building block to
provide congestion controlled reliable asynchronous delivery of
content to an unlimited number of concurrent receivers from a single
sender. This document obsoletes RFC3450.
"Basic Forward Error Correction (FEC) Schemes", Mark Watson, 31-Oct-08,
<draft-ietf-rmt-bb-fec-basic-schemes-revised-06.txt>
This document provides Forward Error Correction (FEC) Scheme
specifications according to the RMT FEC Building Block for the
Compact No-Code FEC Scheme, the Small Block, Large Block and
Expandable FEC Scheme, the Small Block Systematic FEC Scheme and the
Compact FEC Scheme. This document obsoletes RFC3695 and assumes
responsibility for the FEC Schemes defined in RFC3452.
"FLUTE - File Delivery over Unidirectional Transport", Michael Luby, Rami
Lehtonen, Vincent Roca, Toni Paila, 25-Sep-08,
<draft-ietf-rmt-flute-revised-06.txt>
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.
"NACK-Oriented Reliable Multicast Protocol", Brian Adamson, Carsten Bormann,
University London, Joseph Macker, 25-Oct-08,
<draft-ietf-rmt-pi-norm-revised-07.txt,.pdf>
This document describes the messages and procedures of the Negative-
ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol.
This protocol is designed to provide end-to-end reliable transport of
bulk data objects or streams over generic IP multicast routing and
forwarding services. NORM uses a selective, negative acknowledgment
mechanism for transport reliability and offers additional protocol
mechanisms to allow for operation with minimal a priori coordination
among senders and receivers. A congestion control scheme is
specified to allow the NORM protocol to fairly share available
network bandwidth with other transport protocols such as Transmission
Control Protocol (TCP). It is capable of operating with both
reciprocal multicast routing among senders and receivers and with
asymmetric connectivity (possibly a unicast return path) between the
senders and receivers. The protocol offers a number of features to
allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways. The
protocol leverages the use of FEC-based repair and other IETF
reliable multicast transport (RMT) building blocks in its design.
"Multicast Negative-Acknowledgment (NACK) Building Blocks", Brian Adamson,
Carsten Bormann, University London, Joseph Macker, 9-Sep-08,
<draft-ietf-rmt-bb-norm-revised-07.txt,.pdf>
This document discusses the creation of reliable multicast protocols
utilizing negative-acknowledgment (NACK) feedback. The rationale for
protocol design goals and assumptions are presented. Technical
challenges for NACK-based (and in some cases general) reliable
multicast protocol operation are identified. These goals and
challenges are resolved into a set of functional "building blocks"
that address different aspects of reliable multicast protocol
operation. It is anticipated that these building blocks will be
useful in generating different instantiations of reliable multicast
protocols. This document obsoletes RFC 3941.
"Reed-Solomon Forward Error Correction (FEC) Schemes", Jerome Lacan, Vincent
Roca, Jani Peltotalo, Sami Peltotalo, 12-Nov-07,
<draft-ietf-rmt-bb-fec-rs-05.txt>
This document describes a Fully-Specified Forward Error Correction
(FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), with m in
{2..16}, and its application to the reliable delivery of data objects
on the packet erasure channel (i.e., a communication path where
packets are either received without any corruption or discarded
during transmission).
This document also describes a Fully-Specified FEC Scheme for the
special case of Reed-Solomon codes over GF(2^^8) when there is no
encoding symbol group.
Finally, in the context of the Under-Specified Small Block Systematic
FEC Scheme (FEC Encoding ID 129), this document assigns an FEC
Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable
(MDS) codes, i.e., they enable a receiver to recover the k source
symbols from any set of k received symbols. The schemes described
here are compatible with the implementation from Luigi Rizzo.
"Security and Reliable Multicast Transport Protocols: Discussions and
Guidelines", Brian Adamson, Vincent Roca, Hitoshi Asaeda, 3-Nov-08,
<draft-ietf-rmt-sec-discussion-03.txt,.pdf>
This document describes general security considerations for the
Reliable Multicast Transport (RMT) Working Group set of building
blocks and protocols. An emphasis is placed on risks that might be
resolved in the scope of transport protocol design. However,
relevant security issues related to IP Multicast control-plane and
other concerns not strictly within the scope of reliable transport
protocol design are also discussed. The document also begins an
exploration of approaches that could be embraced to mitigate these
risks. The purpose of this document is to provide a consolidated
security discussion and provide a basis for further discussions and
potential resolution of any significant security issues that may
exist in the current set of RMT standards.
"Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca,
27-Oct-08, <draft-ietf-rmt-simple-auth-for-alc-norm-00.txt>
This document introduces two schemes that provide a per-packet
authentication and integrity service in the context of the ALC and
NORM protocols. The first scheme is based on digital signatures.
Because it relies on asymmetric cryptography, this scheme generates a
high processing load at the sender and to a lesser extent at a
receiver, as well as a significant transmission overhead. It is
therefore well suited to low data rate sessions. The second scheme
relies on a group Message Authentication Code (MAC). Because this
scheme relies symmetric cryptography, MAC calculation and
verification are fast operations, which makes it suited to high data
rate sessions. However it only provides a group authentication and
integrity service, which means that it only protects against
attackers that are not group members.
Robust Header Compression (rohc)
--------------------------------
"Integration of Robust Header Compression (ROHC) over IPsec Security
Associations", Emre Ertekin, Rohan Jassani, Chris Christou, Jonah Pezeshki,
Carsten Bormann, 14-Oct-08, <draft-ietf-rohc-hcoipsec-09.txt>
IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for
integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).
By compressing the inner headers of IP packets, ROHCoIPsec proposes
to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs).
"IKEv2 Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec)", Emre Ertekin, Chris Christou, Rohan Jassani, Jonah Pezeshki,
14-Oct-08, <draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt>
In order to integrate ROHC with IPsec [ROHCOIPSEC], a mechanism is
needed to negotiate ROHC configuration parameters between end-points.
Internet Key Exchange (IKE) is a mechanism which can be leveraged to
handle these negotiations. This document specifies extensions to
IKEv2 [IKEV2] that will allow ROHC and its associated configuration
parameters to be negotiated for IPsec security associations (SAs).
"IPsec Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec)", Emre Ertekin, Chris Christou, Jonah Pezeshki, Michele Casey,
Carsten Bormann, 14-Oct-08,
<draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt>
Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits
of IP security services and efficient bandwidth utilization.
However, extensions to the SPD and SAD are required in order to
integrate ROHC with IPsec. This document describes the IPsec
extensions required to support ROHCoIPsec.
"The RObust Header Compression (ROHC) Framework", Kristofer Sandlund,
Ghyslain Pelletier, Lars-Erik Jonsson, 4-Aug-08,
<draft-ietf-rohc-rfc4995bis-00.txt>
The Robust Header Compression (ROHC) protocol provides an efficient,
flexible, and future-proof header compression concept. It is
designed to operate efficiently and robustly over various link
technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was
initially defined in RFC 3095. To improve and simplify the ROHC
specifications, this document explicitly defines the ROHC framework
and the profile for uncompressed separately. More specifically, the
definition of the framework does not modify or update the definition
of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability
issue that was erroneously introduced in RFC 4995, and adds some
minor clarifications.
Routing Over Low power and Lossy networks (roll)
------------------------------------------------
"Urban WSNs Routing Requirements in Low Power and Lossy Networks", Mischa
Dohler, Thomas Watteyne, Tim Winter, Dominique Barthel, Christian Jacquenet,
Giyyarpuram Madhusudan, Gabriel Chegaray, 21-Oct-08,
<draft-ietf-roll-urban-routing-reqs-02.txt>
The application-specific routing requirements for Urban Low Power and
Lossy Networks (U-LLNs) are presented in this document. In the near
future, sensing and actuating nodes will be placed outdoors in urban
environments so as to improve the people's living conditions as well
as to monitor compliance with increasingly strict environmental laws.
These field nodes are expected to measure and report a wide gamut of
data, such as required in smart metering, waste disposal,
meteorological, pollution and allergy reporting applications. The
majority of these nodes is expected to communicate wirelessly which -
given the limited radio range and the large number of nodes -
requires the use of suitable routing protocols. The design of such
protocols will be mainly impacted by the limited resources of the
nodes (memory, processing power, battery, etc.) and the
particularities of the outdoor urban application scenarios. As such,
for a wireless Routing Over Low power and Lossy networks (ROLL)
solution to be useful, the protocol(s) ought to be energy-efficient,
scalable, and autonomous. This documents aims to specify a set of
requirements reflecting these and further U-LLNs tailored
characteristics.
"Industrial Routing Requirements in Low Power and Lossy Networks", Dust
Networks, Pascal Thubert, Sicco Dwars, Tom Phinney, 30-Oct-08,
<draft-ietf-roll-indus-routing-reqs-02.txt>
Wireless, low power field devices enable industrial users to
significantly increase the amount of information collected and the
number of control points that can be remotely managed. The
deployment of these wireless devices will significantly improve the
productivity and safety of the plants while increasing the efficiency
of the plant workers by extending the information set available from
wired systems. In an industrial environment, low power, high
reliability, and easy installation and maintenance are mandatory
qualities for wireless devices. The aim of this document is to
analyze the requirements for the routing protocol used for Low power
and Lossy Networks (LLN) in industrial environments.
"Home Automation Routing Requirements in Low Power and Lossy Networks",
Giorgio Porcu, 19-Nov-08, <draft-ietf-roll-home-routing-reqs-06.txt>
This document presents home control and automation application
specific requirements for Routing Over Low power and Lossy
networks (ROLL). In a modern home, a high number of wireless
devices are used for a wide set of purposes. Examples include
actuators (relay, light dimmer, heating valve), sensors (wall
switch, water leak, blood pressure) and advanced controllers.
Because such devices only cover a limited radio range, routing is
often required. The aim of this document is to specify the routing
requirements for networks comprising such constrained devices in a
home control and automation environment.
"Overview of Existing Routing Protocols for Low Power and Lossy Networks",
Arsalan Tavakoli, Stephen Dawson-Haggerty, P Levis, 17-Oct-08,
<draft-ietf-roll-protocols-survey-02.txt>
Networks of low power wireless devices introduce novel IP routing
issues. Low-power wireless devices, such as sensors, actuators and
smart objects, have difficult constraints: very limited memory,
little processing power, and long sleep periods. As most of these
devices are battery-powered, energy efficiency is critically
important. Wireless link qualities can vary significantly over time,
requiring protocols to make agile decisions yet minimize topology
change energy costs. Routing over such low power and lossy networks
has novel requirements that existing protocols may not address. This
document provides a brief survey of the strengths and weaknesses of
existing protocols with respect to this class of networks. From this
survey it examines whether existing protocols as described in RFCs
and mature drafts could be used without modification in these
networks, or whether further work is necessary.
"Terminology in Low power And Lossy Networks", JP Vasseur, 27-Oct-08,
<draft-ietf-roll-terminology-00.txt>
The documents defines a terminology for discussing routing
requirements and solutions for networks referred to as Low power and
Lossy Networks (LLN). A LLN is typically composed of many embedded
devices with limited power, memory, and processing resources
interconnected by a variety of links. There is a wide scope of
application areas for LLNs, including industrial monitoring, building
automation (e.g. Heating, Ventilating, Air Conditioning, lighting,
access control, fire), connected home, healthcare, environmental
monitoring, urban sensor networks, energy management, assets
tracking, refrigeration.
"Building Automation Routing Requirements in Low Power and Lossy Networks",
Jerry Martocci, Nicolas Riou, Pieter Mil, Wouter Vermeylen, 29-Oct-08,
<draft-ietf-roll-building-routing-reqs-01.txt>
The Routing Over Low power and Lossy network (ROLL) Working Group has
been chartered to work on routing solutions for Low Power and Lossy
networks (LLN) in various markets: Industrial, Commercial (Building),
Home and Urban. Pursuant to this effort, this document defines the
routing requirements for building automation.
Routing Protocol Security Requirements (rpsec)
----------------------------------------------
"BGP Security Requirements", Blaine Christian, Tony Tauber, 3-Nov-08,
<draft-ietf-rpsec-bgpsecrec-10.txt>
The security of BGP, the Border Gateway Protocol, is critical to the
proper operation of large-scale internetworks, both public and
private. While securing the information transmitted between two BGP
speakers is a relatively easy technical matter, securing BGP, as a
routing system, is more complex. This document describes a set of
requirements for securing BGP and the routing information carried
within BGP.
"BGP Session Security Requirements", Michael Behringer, 10-Jul-08,
<draft-ietf-rpsec-bgp-session-sec-req-01.txt>
The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec)
specifies general security requirements for BGP. However, specific
security requirements for single BGP sessions, i.e., the connection
between two BGP peers, are only touched on briefly in the section
"transport layer protection". This document expands on this
particular aspect of BGP security, defining the security requirements
between two BGP peers.
Reliable Server Pooling (rserpool)
----------------------------------
"Reliable Server Pooling: Management Information Base using SMIv2", Thomas
Dreibholz, Jaiwant Mulik, 18-Nov-08, <draft-ietf-rserpool-mib-08.txt>
RSerPool [RFC5351] is a framework to provide reliable server pooling.
This document defines a SMIv2 compliant Management Information Base
(MIB) providing access to managed objects in an RSerPool
implementation.
Routing Area Working Group (rtgwg)
----------------------------------
"IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 30-Oct-08,
<draft-ietf-rtgwg-ipfrr-framework-09.txt>
This document provides a framework for the development of IP fast-
reroute mechanisms which provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS
Fast-reroute, the mechanisms are applicable to a network employing
conventional IP routing and forwarding. An essential part of such
mechanisms is the prevention of packet loss caused by the loops which
normally occur during the re-convergence of the network following a
failure.
"IP Fast Reroute Using Not-via Addresses", Mike Shand, Stewart Bryant,
Stefano Previdi, 30-Oct-08, <draft-ietf-rtgwg-ipfrr-notvia-addresses-03.txt>
This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics.
"A Framework for Loop-free Convergence", Mike Shand, Stewart Bryant,
31-Oct-08, <draft-ietf-rtgwg-lf-conv-frmwk-03.txt>
This draft describes mechanisms that may be used to prevent or to
suppress the formation of micro-loops when an IP or MPLS network
undergoes topology change due to failure, repair or management
action.
Simple Authentication and Security Layer (sasl)
-----------------------------------------------
"The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 11-Jul-08,
<draft-ietf-sasl-crammd5-10.txt>
This document defines a simple challenge-response authentication
mechanism, using a keyed MD5 digest, for use with the Simple
Authentication and Security Layer (SASL).
"Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon
Josefsson, 13-Jul-08, <draft-ietf-sasl-gs2-10.txt>
This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific
notion of channel binding.
See <http://josefsson.org/sasl-gs2-*/> for more information.
"Moving DIGEST-MD5 to Historic", Alexey Melnikov, 29-Jul-08,
<draft-ietf-sasl-digest-to-historic-00.txt>
This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in
the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to
Historic status.
Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
ietf-sasl@imc.org.
"Simple Authentication and Security Layer (SASL)", Alexey Melnikov, Kurt
Zeilenga, 31-Aug-08, <draft-ietf-sasl-4422bis-00.txt>
The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms. It
provides a structured interface between protocols and mechanisms.
The resulting framework allows new protocols to reuse existing
mechanisms and allows old protocols to make use of new mechanisms.
The framework also provides a protocol for securing subsequent
protocol exchanges within a data security layer.
This document describes how a SASL mechanism is structured, describes
how protocols include support for SASL, and defines the protocol for
carrying a data security layer over a connection. In addition, this
document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 4422 [[when approved]].
Site Multihoming by IPv6 Intermediation (shim6)
-----------------------------------------------
"Failure Detection and Locator Pair Exploration Protocol for IPv6
Multihoming", Jari Arkko, Iljitsch van Beijnum, 24-Jun-08,
<draft-ietf-shim6-failure-detection-13.txt,.pdf>
This document specifies how the level 3 multihoming shim protocol
(SHIM6) detects failures between two communicating hosts. It also
specifies an exploration protocol for switching to another pair of
interfaces and/or addresses between the same hosts if a failure
occurs and an operational pair can be found.
"Hash Based Addresses (HBA)", Marcelo Bagnulo, 22-Dec-07,
<draft-ietf-shim6-hba-05.txt>
This memo describes a mechanism to provide a secure binding between
the multiple addresses with different prefixes available to a host
within a multihomed site. This mechanism employs either
Cryptographically Generated Addresses (CGAs) or a new variant of the
same theme that uses the same format in the addresses. The main idea
in the new variant is that information about the multiple prefixes is
included within the addresses themselves. This is achieved by
generating the interface identifiers of the addresses of a host as
hashes of the available prefixes and a random number. Then, the
multiple addresses are generated by prepending the different prefixes
to the generated interface identifiers. The result is a set of
addresses, called Hash Based Addresses (HBAs), that are inherently
bound to each other.
"Shim6: Level 3 Multihoming Shim Protocol for IPv6", Erik Nordmark, Marcelo
Bagnulo, 14-Feb-08, <draft-ietf-shim6-proto-10.txt>
This document defines the Shim6 protocol, a layer 3 shim for
providing locator agility below the transport protocols, so that
multihoming can be provided for IPv6 with failover and load sharing
properties, without assuming that a multihomed site will have a
provider independent IPv6 address prefix which is announced in the
global IPv6 routing table. The hosts in a site which has multiple
provider allocated IPv6 address prefixes, will use the Shim6 protocol
specified in this document to setup state with peer hosts, so that
the state can later be used to failover to a different locator pair,
should the original one stop working.
"Default Locator-pair selection algorithm for the SHIM6 protocol", Marcelo
Bagnulo, 23-Oct-08, <draft-ietf-shim6-locator-pair-selection-04.txt>
In this note, we present a locator-pair selection mechanism for the
shim6 protocol. The presented mechanism provides an ordered list of
available locator-pairs that can be used for outgoing traffic.
"Socket Application Program Interface (API) for Multihoming Shim", Miika
Komu, Marcelo Bagnulo, Kristian Slavov, Shinta Sugimoto, 2-Nov-08,
<draft-ietf-shim6-multihome-shim-api-07.txt>
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.
Secure Inter-Domain Routing (sidr)
----------------------------------
"A Profile for X.509 PKIX Resource Certificates", Geoff Huston, George
Michaelson, Robert Loomans, 17-Nov-08, <draft-ietf-sidr-res-certs-15.txt>
This document defines a standard profile for X.509 certificates for
the purposes of supporting validation of assertions of "right-of-use"
of an Internet Number Resource (IP Addresses and Autonomous System
Numbers). This profile is used to convey the issuer's authorization
of the subject to be regarded as the current holder of a "right-of-
use" of the IP addresses and AS numbers that are described in the
issued certificate.
"Certificate Policy (CP) for the Resource PKI (RPKI)", Stephen Kent, Derrick
Kong, Karen Seo, 3-Nov-08, <draft-ietf-sidr-cp-04.txt>
This document describes the certificate policy for a PKI used to
support improved routing security. Each organization that allocates
IP addresses or Autonomous System (AS) numbers to an organization
will, in parallel, issue a certificate reflecting this allocation.
These certificates will enable verification that the holder of the associated
private key has been allocated the resources indicated in the certificate,
and is the current, unique holder of these resources. The PKI in which the
certificates issued under this policy are employed, in conjunction with ancillary
digitally signed data structures, will provide critical inputs for routing
security mechanisms, e.g., generation of route filters by ISPs.
"Template for an Internet Registry's Certification Practice Statement (CPS)
for the Resource PKI (RPKI)", Derrick Kong, Karen Seo, Stephen Kent,
3-Nov-08, <draft-ietf-sidr-cps-irs-04.txt>
This document contains a template to be used for creating a
Certification Practice Statement (CPS) for an Internet Registry
(e.g., NIR or RIR) that is part of the Resource Public Key
Infrastructure (RPKI).
"Template for an Internet Service Provider's Certification Practice Statement
(CPS) for the Resource PKI (RPKI)", Karen Seo, Stephen Kent, Dennis Kong,
3-Nov-08, <draft-ietf-sidr-cps-isp-03.txt>
This document contains a template to be used for creating a
Certification Practice Statement (CPS) for a Local Internet Registry
(LIR) or Internet Service Provider (ISP) that is part of the Resource
Public Key Infrastructure (PKI).
"A Profile for Route Origin Authorizations (ROAs)", Matt Lepinski, Stephen
Kent, Derrick Kong, 3-Nov-08, <draft-ietf-sidr-roa-format-04.txt>
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.
"An Infrastructure to Support Secure Internet Routing", Matt Lepinski,
Stephen Kent, 3-Nov-08, <draft-ietf-sidr-arch-04.txt>
This document describes an architecture for an infrastructure to
support improved security of Internet routing. The foundation of this
architecture is a public key infrastructure (PKI) that represents the
allocation hierarchy of IP address space and Autonomous System
Numbers; and a distributed repository system for storing and
disseminating the data objects that comprise the PKI, as well as
other signed objects necessary for improved routing security. As an
initial application of this architecture, the document describes how
a holder of IP address space can explicitly and verifiably authorize
one or more ASes to originate routes to that address space. Such
verifiable authorizations could be used, for example, to more
securely construct BGP route filters.
"A Protocol for Provisioning Resource Certificates", Geoff Huston, Robert
Loomans, Byron Ellacott, Rob Austein, 6-Aug-08,
<draft-ietf-sidr-rescerts-provisioning-03.txt>
This document defines a framework for certificate management
interactions between a resource issuer ("Internet Registry" or "IR")
and a resource recipient ("Internet Service Provider" or "ISP")
through the specification of a protocol for interaction between the
two parties. The protocol supports the transmission of requests from
the ISP, and corresponding responses from the IR 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.
"Manifests for the Resource Public Key Infrastructure", Rob Austein, Geoff
Huston, Stephen Kent, Matt Lepinski, 24-Oct-08,
<draft-ietf-sidr-rpki-manifests-04.txt>
This document defines a "manifest" for use in the Resource Public Key
Infrastructure. A manifest is a signed object that contains a
listing of all the signed objects in the repository publication point
associated with an authority responsible for publishing in the
repository. For each certificate, or other forms of signed objects
issued by the authority that are published at this repository
publication point, the manifest contains both the name of the file
containing the object, and a hash of the file content. Manifests are
intended to expose potential attacks against relying parties of the
Resource Public Key Infrastructure, such as a man-in-the middle
attack of withholding repository data from relying party access, or
replaying stale repository data to a relying party's access request.
"Validation of Route Origination in BGP using the Resource Certificate PKI",
Geoff Huston, George Michaelson, 5-Oct-08,
<draft-ietf-sidr-roa-validation-01.txt>
This document defines an application of the Resource Public Key
Infrastructure to validate the origination of routes advertised in
the Border Gateway Protocol. The proposed application is intended to
fit within the requirements for adding security to inter-domain
routing, including the ability to support incremental and piecemeal
deployment, and does not require any changes to the specification of
BGP.
"A Profile for Bogon Origin Attestations (BOAs)", Geoff Huston, George
Michaelson, Terry Manderson, 28-Oct-08, <draft-ietf-sidr-bogons-02.txt>
This document defines a standard profile for Bogon Origin
Attestations (BOAs). A BOA is a digitally signed object that
provides a means of verifying that an IP address block holder has not
authorized any Autonomous System (AS) to originate routes that are
equivalent to any of the addresses listed in the BOA. A BOA also
provides a means of verifying that BGP speaker is not using an AS
without appropriate authority to use that AS. The proposed
application of BOAs is intended to fit within the requirements for
adding security measures to inter-domain routing, including the
ability to support incremental and piecemeal deployment of such
measures, and does not require any changes to the specification of
the Border Gateway Protocol.
"A Profile for Resource Certificate Repository Structure", Geoff Huston,
Robert Loomans, George Michaelson, 4-Oct-08,
<draft-ietf-sidr-repos-struct-01.txt>
This document defines a profile for the structure of repository
publication points that contain X.509 / PKIX Resource Certificates,
Certificate Revocation Lists and signed objects. This profile
contains the proposed object naming scheme, the contents of
repository publication points, the contents of publication point
manifests and a suggested internal structure of a local repository
cache that is intended to facilitate synchronization across a
distributed collection of repository publication points and
facilitate certification path construction.
Sieve Mail Filtering Language (sieve)
-------------------------------------
"Sieve Email Filtering: Reject and Extended Reject Extensions", Aaron Stone,
Matthew Elvey, Alexey Melnikov, 17-Nov-08,
<draft-ietf-sieve-refuse-reject-09.txt>
This memo updates the definition of the Sieve mail filtering language
"reject" extension, originally defined in RFC 3028.
A "Joe-job" is a spam run forged to appear as though it came from an
innocent party, who is then generally flooded by automated bounces,
Message Disposition Notifications (MDNs), and personal messages with
complaints. The original Sieve "reject" action defined in RFC 3028
required use of MDNs for rejecting messages, thus contributing to the
flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow
messages to be refused during the SMTP transaction, and defines the
"ereject" action to require messages to be refused during the SMTP
transaction, if possible.
The "ereject" action is intended to replace the "reject" action
wherever possible. The "ereject" action is similar to "reject", but
will always favor protocol level message rejection.
"SIEVE Email Filtering: Extension for Notifications", Alexey Melnikov, Barry
Leiba, Wolfgang Segmuller, Tim Martin, 24-Dec-07,
<draft-ietf-sieve-notify-12.txt>
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but it is expected that using existing instant messaging
infrastructure such as XMPP, or GSM Short Message Service (SMS)
messages will be popular. This draft describes an extension to the
Sieve mail filtering language that allows users to give specific
rules for how and when notifications should be sent.
"Sieve Notification Mechanism: mailto", Barry Leiba, Michael Haardt,
1-Oct-08, <draft-ietf-sieve-notify-mailto-09.txt>
This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.
"Sieve Notification Mechanism: xmpp", Peter Saint-Andre, Alexey Melnikov,
19-Feb-08, <draft-ietf-sieve-notify-xmpp-09.txt>
This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the Extensible
Messaging and Presence Protocol (XMPP), also known as Jabber.
"Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement
and Enclosure", Tony Hansen, Cyrus Daboo, 20-Nov-08,
<draft-ietf-sieve-mime-loop-08.txt>
This document defines extensions to the Sieve email filtering
language to permit analysis and manipulation of the MIME body parts
of an email message.
Note
This document is being discussed on the MTA-FILTERS mailing list,
ietf-mta-filters@imc.org.
"Sieve Email Filtering: Ihave Extension", Ned Freed, 9-Oct-08,
<draft-freed-sieve-ihave-03.txt>
This document describes the "ihave" extension to the Sieve email
filtering language. The "ihave" extension provides a means to write
scripts that can take advantage of optional Sieve features but can
still run when those optional features are not available. The
extension also defines a new error control command intended to be
used to report situations where no combination of available
extensions satisfies the needs of the script.
"Sieve Email Filtering: Delivery Status Notifications Extension", Ned Freed,
17-Nov-08, <draft-freed-sieve-notary-02.txt>
This document describes the "dsn-envelope" and "dsn-redirect"
extensions to the Sieve email filtering language. The "dsn-envelope"
extension provides access to additional envelope information provided
by the delivery status notification extension to SMTP defined in RFC
3461. The "dsn-redirect" extension extends Sieve's redirect action
to provide control over delivery status notification parameters.
"A Protocol for Remotely Managing Sieve Scripts", Alexey Melnikov, Tim
Martin, 1-Nov-08, <draft-ietf-sieve-managesieve-01.txt>
Sieve scripts allow users to filter incoming email. Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them. This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server. This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.
SIP for Instant Messaging and Presence Leveraging Extensions (simple)
---------------------------------------------------------------------
"An Extensible Markup Language (XML) Document Format for Indicating A Change
in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg,
Jari Urpalainen, 5-May-08, <draft-ietf-simple-xcap-diff-09.txt>
This specification defines a document format that can be used to
indicate that a change has occurred in a document managed by the
Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). This format indicates the document that has changed and its
former and new entity tags. It also can indicate the specific change
that was made in the document, using an XML patch format. This
format allows also indications of element and attribute content of an
XML document. XCAP diff documents can be delivered to clients using
a number of means, including a Session Initiation Protocol (SIP)
event package.
"Instant Message Disposition Notification", Eric Burger, Hisham Khartabil,
19-Oct-08, <draft-ietf-simple-imdn-09.txt>
Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing, and displayed notifications,
for page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified
in RFC 3862 is extended with new header fields that enable endpoints
to request IMDNs. A new message format is also defined to convey
IMDNs.
This document also describes how SIP entities behave using this
extension.
"Presence Interdomain Scaling Analysis for SIP/SIMPLE", Avshalom Houri, Edwin
Aoki, Sriram Parameswar, Tim Rang, Vishal Singh, Henning Schulzrinne,
22-Oct-08, <draft-ietf-simple-interdomain-scaling-analysis-05.txt>
The document analyzes the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of
traffic can be extremely big. In addition to the very large traffic
the document also analyzes the affects of a large presence system on
the memory footprint and the CPU load. Current approved and in work
optimizations to the SIP protocol are analyzed with the possible
impact on the load. Separate documents contain the requirements for
optimizations and suggestions for new optimizations.
"Multi-party Chat Using the Message Session Relay Protocol (MSRP)", Aki
Niemi, Miguel Garcia-Martin, Geir Arne Sandbakken, 30-Oct-08,
<draft-ietf-simple-chat-03.txt>
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a peer-to-peer session, negotiated
using the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP). This document defines the necessary
tools for establishing multi-party chat sessions, or chat rooms,
using MSRP.
"SIMPLE made Simple: An Overview of the IETF Specifications for Instant
Messaging and Presence using the Session Initiation Protocol (SIP)", Jonathan
Rosenberg, 31-Oct-08, <draft-ietf-simple-simple-04.txt>
The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP).
Collectively, these specifications are known as SIMPLE - SIP for
Instant Messaging and Presence Leveraging Extensions. This document
serves as a guide to the SIMPLE suite of specifications. It breaks
them up into categories and explains what each is for and how they
relate to each other.
"Optimizing Federated Presence with View Sharing", Jonathan Rosenberg, Steve
Donovan, Kathleen McMurry, 3-Nov-08, <draft-ietf-simple-view-sharing-02.txt>
Presence federation refers to the exchange of presence information
between systems. One of the primary challenges in presence
federation is scale. With a large number of watchers in one domain
obtaining presence for many presentities in another, the amount of
notification traffic is large. This document describes an extension
to the Session Initiation Protocol (SIP) event framework, called view
sharing. View sharing can substantially reduce the amount of
traffic, but requires a certain level of trust between domains. View
sharing allows the amount of presence traffic between domains to
achieve the theoretical lower bound on information exchange in any
presence system.
"Models for Intra-Domain Presence and Instant Messaging (IM) Bridging",
Jonathan Rosenberg, Avshalom Houri, Colm Smyth, Francois Audet, 3-Nov-08,
<draft-ietf-simple-intradomain-federation-02.txt>
Presence and Instant Messaging (IM) bridging involves the sharing of
presence information and exchange of IM across multiple systems
within a single domain. As such, it is a close cousin to presence
and IM federation, which involves the sharing of presence and IM
across differing domains. Presence and IM bridging can be the result
of a multi-vendor network, or a consequence of a large organization
that requires partitioning. This document examines different use
cases and models for intra-domain presence and IM bridging.
Session Initiation Protocol (sip)
---------------------------------
"Connection Reuse in the Session Initiation Protocol (SIP)", Vijay Gurbani,
Rohan Mahy, Brett Tate, 22-Oct-08, <draft-ietf-sip-connect-reuse-12.txt>
This document enables a pair of communicating proxies to reuse a
congestion-controlled connection between themselves for sending
requests in the forward and backwards direction. Because the
connection is essentially aliased for requests going in the backwards
direction, reuse is predicated upon both the communicating endpoints
authenticating themselves using X.509 certificates through TLS. For
this reason, we only consider connection reuse for TLS over TCP and
TLS over SCTP. From the security perspective, it is bad practice to
reuse a single connection for the TCP or SCTP transport between two
peers, and this document provides specific insights into why this is
the case. As a remedy, it suggests using two TCP connections (or two
SCTP associations), each opened pro-actively towards the recipient by
the sender. Finally, this document also provides guidelines on
connection reuse and virtual SIP servers and the interaction of
connection reuse and DNS SRV lookups in SIP.
"Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the
Session Initiation Protocol (SIP)", Jonathan Rosenberg, 11-Oct-07,
<draft-ietf-sip-gruu-15.txt>
Several applications of the Session Initiation Protocol (SIP) require
a user agent (UA) to construct and distribute a URI that can be used
by anyone on the Internet to route a call to that specific UA
instance. A URI that routes to a specific UA instance is called a
Globally Routable UA URI (GRUU). This document describes an
extension to SIP for obtaining a GRUU from a registrar and for
communicating a GRUU to a peer within a dialog.
"Location Conveyance for the Session Initiation Protocol", James Polk, Brian
Rosen, 20-Nov-08, <draft-ietf-sip-location-conveyance-12.txt>
This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end to end
conveyance as well as location-based routing, where SIP servers
make routing decisions based on the location of the user agent
clients.
"Managing Client Initiated Connections in the Session Initiation Protocol
(SIP)", Cullen Jennings, Rohan Mahy, 29-Oct-08,
<draft-ietf-sip-outbound-16.txt>
The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections or to send asynchronous UDP datagrams to
User Agents in order to deliver requests. However, in a large number
of real deployments, many practical considerations, such as the
existence of firewalls and Network Address Translators (NATs) or the
use of TLS with server-provided certificates, prevent servers from
connecting to User Agents in this way. This specification defines
behaviors for User Agents, registrars and proxy servers that allow
requests to be delivered on existing connections established by the
User Agent. It also defines keep alive behaviors needed to keep NAT
bindings open and specifies the usage of multiple connections from
the User Agent to its Registrar.
"Requesting Answering Modes for the Session Initiation Protocol (SIP)", Dean
Willis, Andrew Allen, 28-May-08, <draft-ietf-sip-answermode-07.txt>
This document extends SIP with two header fields and associated
option tags that can be used in INVITE requests to convey the
requester's preference for user-interface handling related to
answering of that request. The first header, "Answer-Mode",
expresses a preference as to whether the target node's user interface
waits for user input before accepting the request or instead accepts
the request without waiting on user input. The second header, "Priv-
Answer-Mode" is similar to the first, except that it requests
administrative-level access and has consequent additional
authentication and authorization requirements. These behaviors have
applicability to applications such as Push-to-Talk and to diagnostics
like loop-back. Usage of each header field in a response to indicate
how the request was handled is also defined.
"Addressing an Amplification Vulnerability in Session Initiation Protocol
(SIP) Forking Proxies", Robert Sparks, Scott Lawrence, Alan Hawrylyshen,
Byron Campen, 29-Oct-08, <draft-ietf-sip-fork-loop-fix-08.txt>
This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address a security vulnerability identified in SIP
proxy behavior. This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP
requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies
when they fork requests (that is, forward a request to more than one
destination). It also corrects and clarifies the description of the
loop-detection algorithm such proxies are required to implement.
Additionally, this document defines a Max-Breadth mechanism for
limiting the number of concurrent branches pursued for any given
request.
"Certificate Management Service for The Session Initiation Protocol (SIP)",
Cullen Jennings, Jason Fischl, 3-Nov-08, <draft-ietf-sip-certs-07.txt>
This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event
package to discover the certificates of other users. This mechanism
allows user agents that want to contact a given Address-of-Record
(AOR) to retrieve that AOR's certificate by subscribing to the
Credential Service, which returns an authenticated response
containing that certificate. The Credential Service also allows
users to store and retrieve their own certificates and private keys.
"SIP SAML Profile and Binding", Hannes Tschofenig, Jeff Hodges, Jon Peterson,
James Polk, Douglas Sicker, 3-Nov-08, <draft-ietf-sip-saml-05.txt>
This document specifies a Session Initiation Protocol (SIP) profile
of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding. The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)".
"A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", Jonathan
Rosenberg, 3-Nov-08, <draft-ietf-sip-hitchhikers-guide-06.txt>
The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. This specification serves
as a guide to the SIP RFC series. It lists a current snapshot of the
specifications under the SIP umbrella, briefly summarizes each, and
groups them into categories.
"A Framework for Session Initiation Protocol (SIP) Session Policies", Volker
Hilt, Gonzalo Camarillo, Jonathan Rosenberg, 1-Nov-08,
<draft-ietf-sip-session-policy-framework-05.txt>
Proxy servers play a central role as an intermediary in the Session
Initiation Protocol (SIP) as they define and impact policies on call
routing, rendezvous, and other call features. This document
specifies a framework for SIP session policies that provides a
standard mechanism by which a proxy can define or influence policies
on sessions, such as the codecs or media types to be used. It
defines a model, an overall architecture and new protocol mechanisms
for session policies.
"The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)",
Francois Audet, 23-Feb-08, <draft-ietf-sip-sips-08.txt>
This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
It also makes normative changes to SIP. This document also provides
a discussion of possible future steps in specification.
"Indicating Support for Interactive Connectivity Establishment (ICE) in the
Session Initiation Protocol (SIP)", Jonathan Rosenberg, 19-Jun-07,
<draft-ietf-sip-ice-option-tag-02.txt>
This specification defines a media feature tag and an option tag for
use with the Session Initiation Protocol (SIP). The media feature
tag allows a UA to communicate to its registrar that it supports ICE.
The option tag allows a User Agent (UA) to require support for ICE in
order for a call to proceed.
"An Extension to Session Initiation Protocol (SIP) Events for Conditional
Event Notification", Aki Niemi, 14-Jul-08,
<draft-ietf-sip-subnot-etags-03.txt>
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures have a serious
deficiency in that they provide no tools to avoid replaying event
notifications that have already been received by a user agent. This
memo defines an extension to SIP events that allows the subscriber to
condition the subscription request to whether the state has changed
since the previous notification was received. When such a condition
is true, either the body of a resulting event notification or the
entire notification message is suppressed.
"Addressing Record-Route issues in the Session Initiation Protocol (SIP)",
Thomas Froment, Christophe Lebel, Ben Bonnaerens, 6-Oct-08,
<draft-ietf-sip-record-route-fix-05.txt>
A typical function of a Session Initiation Protocol (SIP) Proxy is to
insert a Record-Route header into initial, dialog creating requests
in order to make subsequent, in-dialog requests pass through it.
This header contains a SIP Uniform Resource Identifier (URI)
indicating where and how the subsequent requests should be sent to
reach the proxy. Like any SIP URI, it can contain sip or sips
schemes, IPv4 or IPv6 addresses, and URI parameters that could
influence the routing such as the transport parameter (for example
transport=tcp), or a compression indication like "comp=sigcomp".
When a proxy has to change some of those parameters between its
incoming and outgoing interfaces (multi-homed proxies, transport
protocol switching or IPv4 to IPv6 scenarios...), the question arises
on what should be put in Record-Route header(s). It is just not
possible to make one header having the characteristics of both sides
at the same time. This document aims to clarify these scenarios and
fix bugs already identified on this topic; it formally recommends the
use of the double Record-Route technique as an alternative to the
current RFC3261 text, which describes only a Record-Route rewriting
solution.
"Message Body Handling in the Session Initiation Protocol (SIP)", Gonzalo
Camarillo, 18-Nov-08, <draft-ietf-sip-body-handling-05.txt>
This document specifies how message bodies are handled in SIP.
Additionally, this document specifies SIP user agent support for MIME
(Multipurpose Internet Mail Extensions) in message bodies.
"Requirements and Analysis of Media Security Management Protocols", Dan Wing,
Steffen Fries, Hannes Tschofenig, Francois Audet, 31-Oct-08,
<draft-ietf-sip-media-security-requirements-08.txt>
This document describes requirements for a protocol to negotiate a
security context for SIP-signaled SRTP media. In addition to the
natural security requirements, this negotiation protocol must
interoperate well with SIP in certain ways. A number of proposals
have been published and a summary of these proposals is in the
appendix of this document.
"IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority
Namespaces", James Polk, 21-Oct-08,
<draft-ietf-sip-rph-new-namespaces-04.txt>
This document creates additional Session Initiation Protocol (SIP)
Resource-Priority namespaces to meet the requirements of the US
Defense Information Systems Agency, and places these namespaces in
the IANA registry.
"Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509
Certificates", Scott Lawrence, Vijay Gurbani, 6-Oct-08,
<draft-ietf-sip-eku-03.txt>
This memo documents an extended key usage (EKU) X.509 certificate
extension for identifying the holder of a certificate as
authoritative for a Session Initiation Protocol (SIP) service in the
domain named by the DNS name in the certificate.
"Domain Certificates in the Session Initiation Protocol (SIP)", Vijay
Gurbani, Scott Lawrence, Bell Laboratories, 6-Oct-08,
<draft-ietf-sip-domain-certs-02.txt>
This document describes how to interpret certain information in a
X.509 PKIX-compliant certificate used in a Session Initiation
Protocol (SIP) over Transport Layer Security (TLS) connection. More
specifically, this document describes how to find the right identity
for authentication in such certificates and how to use that identity
for SIP domain authentication.
"Framework for Establishing an SRTP Security Context using DTLS", Jason
Fischl, Hannes Tschofenig, Eric Rescorla, 29-Oct-08,
<draft-ietf-sip-dtls-srtp-framework-05.txt>
This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS)
protocol. It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake. The key
exchange travels along the media path as opposed to the signaling
path. The SIP Identity mechanism can be used to protect the
integrity of the fingerprint attribute from modification by
intermediate proxies.
"UA-Driven Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert,
Takumi Ohba, 29-Oct-08, <draft-ietf-sip-ua-privacy-03.txt>
This document defines a best current practice for a user agent to
generate an anonymous SIP message by utilizing mechanisms such as
GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using
Relays around NAT) without the need for a privacy service defined in
RFC 3323.
"An Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
Diff Event Package", Jari Urpalainen, 3-Oct-08,
<draft-ietf-sip-xcapevent-04.txt>
This document describes an "xcap-diff" SIP event package for the SIP
Event Notification Framework, which clients can use to receive
notifications of the partial changes of Extensible Markup Language
(XML) Configuration Access Protocol (XCAP) resources. The initial
synchronization information exchange and document updates are based
on the XCAP-Diff format.
"Response Code for Indication of Terminated Dialog", Christer Holmberg,
20-Oct-08, <draft-ietf-sip-199-02.txt>
This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP entity can use to indicate upstream that an
early dialog has been terminated. The response code can be used by a
SIP entity to indicate to the UAC that an early dialog has been
terminated, before a final response is sent to the UAC.
"Session Initiation Protocol (SIP) INFO Method and Package Framework", Eric
Burger, Hadriel Kaplan, Christer Holmberg, 4-Nov-08,
<draft-ietf-sip-info-events-01.txt>
This document defines the new INFO method and a mechanism for
defining, negotiating and exchanging Info Packages that use the INFO
method. Applications which need to exchange session-related
information within a SIP INVITE-created dialog, also known as
application level information, use these INFO requests. This draft
addresses issues and open items from RFC 2976, and replaces it.
Session Initiation Proposal Investigation (sipping)
---------------------------------------------------
"A Call Control and Multi-party usage framework for the Session Initiation
Protocol (SIP)", Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Dan Petrie,
Alan Johnston, 16-Apr-08, <draft-ietf-sipping-cc-framework-10.txt>
This document defines a framework and requirements for call control
and multi-party usage of SIP. To enable discussion of multi-party
features and applications we define an abstract call model for
describing the media relationships required by many of these. The
model and actions described here are specifically chosen to be
independent of the SIP signaling and/or mixing approach chosen to
actually setup the media relationships. In addition to its dialog
manipulation aspect, this framework includes requirements for
communicating related information and events such as conference and
session state, and session history. This framework also describes
other goals that embody the spirit of SIP applications as used on the
Internet.
"Best Current Practices for NAT Traversal for Client-Server SIP", Chris
Boulton, Jonathan Rosenberg, Gonzalo Camarillo, Francois Audet, 17-Sep-08,
<draft-ietf-sipping-nat-scenarios-09.txt>
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.
"Session Initiation Protocol Call Control - Transfer", Robert Sparks, Alan
Johnston, 15-Oct-08, <draft-ietf-sipping-cc-transfer-11.txt>
This document describes providing Call Transfer capabilities in the
Session Initiation Protocol (SIP). SIP extensions such as REFER and
Replaces are used to provide a number of transfer services including
blind transfer, consultative transfer, and attended transfer. This
work is part of the SIP multiparty call control framework.
"A Framework for Session Initiation Protocol User Agent Profile Delivery",
Sumanth Channabasappa, 13-Feb-08,
<draft-ietf-sipping-config-framework-15.txt>
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.
"A Framework for Application Interaction in the Session Initiation Protocol
(SIP)", Jonathan Rosenberg, 20-Jul-05,
<draft-ietf-sipping-app-interaction-framework-05.txt>
This document describes a framework for the interaction between users
and Session Initiation Protocol (SIP) based applications. By
interacting with applications, users can guide the way in which they
operate. The focus of this framework is stimulus signaling, which
allows a user agent to interact with an application without knowledge
of the semantics of that application. Stimulus signaling can occur
to a user interface running locally with the client, or to a remote
user interface, through media streams. Stimulus signaling
encompasses a wide range of mechanisms, ranging from clicking on
hyperlinks, to pressing buttons, to traditional Dual Tone Multi
Frequency (DTMF) input. In all cases, stimulus signaling is
supported through the use of markup languages, which play a key role
in this framework.
"IPv6 Transition in the Session Initiation Protocol (SIP)", Gonzalo
Camarillo, 17-Aug-07, <draft-ietf-sipping-v6-transition-07.txt>
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.
"Registration Event Package Extension for Session Initiation Protocol (SIP)
Globally Routable User Agent URIs (GRUUs)", Paul Kyzivat, 9-Jul-07,
<draft-ietf-sipping-gruu-reg-event-09.txt>
RFC 3680 defines a Session Initiation Protocol (SIP)[5] event package
for registration state. This package allows a watcher to learn about
information stored by a SIP registrar, including its registered
contact.
However, the registered contact is frequently unreachable and thus
not useful for watchers. The Globally Routable User Agent URI
(GRUU), defined in RFC YYYY [3], is a URI that is capable of reaching
a particular contact. However this URI is not included in the
document format defined in RFC 3680. This specification defines an
extension to the registration event package to include GRUUs assigned
by the registrar.
"A User Agent Profile Data Set for Media Policy", Volker Hilt, Gonzalo
Camarillo, Jonathan Rosenberg, 12-Jul-08,
<draft-ietf-sipping-media-policy-dataset-06.txt>
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 extends the Schema for SIP User
Agent Profile Data Sets. It can be used to describe the properties
of a specific SIP session or to define policies that are then applied
to different SIP sessions.
"Session Initiation Protocol Package for Voice Quality Reporting Event", Alan
Clark, Amy Pendleton, Alan Johnston, Henry Sinnreich, 9-Oct-08,
<draft-ietf-sipping-rtcp-summary-05.txt>
This document defines a SIP event package that enables the collection
and reporting of metrics that measure the quality for Voice over
Internet Protocol (VoIP) sessions.
"A Session Initiation Protocol (SIP) Event Package for Session-Specific
Session Policies.", Volker Hilt, Gonzalo Camarillo, 12-Jul-08,
<draft-ietf-sipping-policy-package-05.txt>
This specification defines a Session Initiation Protocol (SIP) event
package for session-specific policies. This event package enables
user agents to subscribe to session policies for a SIP session and to
receive notifications if these policies change.
"Requirements from SIP (Session Initiation Protocol) Session Border Control
Deployments", Jani Hautakorpi, Gonzalo Camarillo, Bob Penfield, Alan
Hawrylyshen, Medhavi Bhatia, 22-Oct-08, <draft-ietf-sipping-sbc-funcs-07.txt>
This document describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs). The goal of this document is to describe the commonly
provided functions of SBCs. A special focus is given to those
practices that are viewed to be in conflict with SIP architectural
principles. This document also explores the underlying requirements
of network operators that have led to the use of these functions and
practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications
or additional standards work is required.
"Requirements for Management of Overload in the Session Initiation Protocol",
Jonathan Rosenberg, 14-Jul-08, <draft-ietf-sipping-overload-reqs-05.txt>
Overload occurs in Session Initiation Protocol (SIP) networks when
proxies and user agents have insuffient resources to complete the
processing of a request. SIP provides limited support for overload
handling through its 503 response code, which tells an upstream
element that it is overloaded. However, numerous problems have been
identified with this mechanism. This draft summarizes the problems
with the existing 503 mechanism, and provides some requirements for a
solution.
"SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", Paul
Kyzivat, 3-Nov-08, <draft-ietf-sipping-sip-offeranswer-09.txt>
The Session Initiation Protocol (SIP) utilizes the offer/answer
model to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP
communication.
"Example calls flows of race conditions in the Session Initiation Protocol
(SIP)", Miki Hasebe, Jun Koshiko, Yasushi Suzuki, Tomoyuki Yoshikawa, Paul
Kyzivat, 29-Sep-08, <draft-ietf-sipping-race-examples-06.txt>
This document gives examples call flows of race conditions in the
Session Initiation Protocol (SIP). Race conditions are inherently
confusing and difficult to thwart; this document shows the best
practices to handle them. The elements in these call flows include
SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details
are given.
"Identification of Communications Services in the Session Initiation Protocol
(SIP)", Jonathan Rosenberg, 4-Aug-08,
<draft-ietf-sipping-service-identification-03.txt>
This document considers the problem of service identification in the
Session Initiation Protocol (SIP). Service identification is the
process of determining the user-level use case that is driving the
signaling being utilized by the user agent. This document discusses
the uses of service identification, and outlines several
architectural principles behind the process. It identifies perils
when service identification is not done properly - including fraud,
interoperability failures and stifling of innovation.
"Scaling Requirements for Presence in SIP/SIMPLE", Avshalom Houri, Sriram
Parameswar, Edwin Aoki, Vishal Singh, Henning Schulzrinne, 2-Nov-08,
<draft-ietf-sipping-presence-scaling-requirements-02.txt>
The document provides a set of requirements for enabling interdomain
scaling in presence for SIP/SIMPLE.
"Updates to Asserted Identity in the Session Initiation Protocol (SIP)", John
Elwell, 13-Oct-08, <draft-ietf-sipping-update-pai-07.txt>
SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header
field. This header field is specified for use in requests using a
number of SIP methods, in particular the INVITE method. However, RFC
3325 does not specify the insertion of this header field by a trusted
UAC, does not specify the use of P-Asserted-Identity and P-Preferred-
Identity header fields with certain SIP methods such as UPDATE,
REGISTER, MESSAGE, PUBLISH and ACK, and does not specify how to
handle an unexpected number of URIs or unexpected URI schemes in
these header fields. This document extends RFC 3325 to cover these
situations.
This work is being discussed on the sipping@ietf.org mailing list.
"A Schema and Guidelines for Defining Session Initiation Protocol User Agent
Profile Datasets", Martin Dolly, Sumanth Channabasappa, Sam Ganesan, Volker
Hilt, 30-Oct-08, <draft-ietf-sipping-profile-datasets-02.txt>
This document defines the requirements and a format for SIP user
agent profile data. An overall schema is specified for the
definition of profile datasets. The schema also provides for
expressing constraints for how multiple sources of profile data are
to be combined. This document provides a guide to considerations,
policies and syntax for defining datasets to be included in profile
data.
"Design Considerations for Session Initiation Protocol (SIP) Overload
Control", Volker Hilt, 22-Oct-08, <draft-ietf-sipping-overload-design-00.txt>
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document discusses models and design considerations for a SIP
overload control mechanism.
S/MIME Mail Security (smime)
----------------------------
"Use of the RSA-KEM Key Transport Algorithm in CMS", James Randall, Burton
Kaliski, 10-Nov-08, <draft-ietf-smime-cms-rsa-kem-06.txt>
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions
for using the RSA-KEM Key Transport Algorithm with the Cryptographic
Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and
ISO/IEC 18033-2.
"Identity-based Encryption Architecture and Supporting Data Structures",
Guido Appenzeller, Luther Martin, Mark Schertler, 9-Oct-08,
<draft-ietf-smime-ibearch-09.txt>
This document describes the security architecture required to
implement identity-based encryption, a public-key encryption
technology that uses a user's identity as a public key. It
also defines data structures that can be used to implement the
technology.
"Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption
Algorithms with the Cryptographic Message Syntax (CMS)", Luther Martin, Mark
Schertler, 4-Aug-08, <draft-ietf-smime-bfibecms-10.txt>
This document describes the conventions for using the Boneh-
Franklin (BF) and Boneh-Boyen (BB1) identity-based
encryption algorithms in the Cryptographic Message Syntax
(CMS) to encrypt content-encryption keys. Object identifiers
and the convention for encoding a recipient's identity are
also defined.
"Multiple Signatures in S/MIME", Sean Turner, Jim Schaad, 11-Mar-08,
<draft-ietf-smime-multisig-05.txt>
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo
structure to convey per-signer information. SignedData supports
multiple signers and multiple signature algorithms per-signer with
multiple SignerInfo structures. If a signer attaches more than one
SignerInfo, there are concerns that an attacker could perform a
downgrade attack by removing the SignerInfo(s) with the 'strong'
algorithm(s). This document defines the multiple-signatures
attribute, its generation rules, and its processing rules to allow
signers to convey multiple SignerInfo while protecting against
downgrade attacks. Additionally, this attribute may assist during
periods of algorithm migration.
"Using SHA2 Algorithms with Cryptographic Message Syntax", Sean Turner,
9-Oct-08, <draft-ietf-smime-sha2-09.txt>
his document describes the conventions for using the Secure Hash
Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,
SHA-512) with the Cryptographic Message Syntax (CMS). It also
describes the conventions for using these algorithms with CMS and the
Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and
Elliptic Curve DSA (ECDSA) signature algorithms.
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Certificate Handling", Sean Turner, Blake Ramsdell, 6-Oct-08,
<draft-ietf-smime-3850bis-08.txt>
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME
provides a method to send and receive secure MIME messages, and
certificates are an integral part of S/MIME agent processing. S/MIME agents
validate certificates as described in RFC 5280, the Internet X.509 Public
Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the
certificate processing requirements in this document as well as those in
RFC 5280. This document obsoletes RFC 3850.
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", Blake Ramsdell, Sean Turner, 6-Oct-08,
<draft-ietf-smime-3851bis-08.txt>
This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.2. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin. Encryption provides
data confidentiality. Compression can be used to reduce data size. This
document obsoletes RFC 3851.
"New ASN.1 Modules for CMS and S/MIME", Paul Hoffman, Jim Schaad, 10-Jul-08,
<draft-ietf-smime-new-asn1-01.txt>
The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1. There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.
"Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", Sean Turner, Daniel R. L. Brown, 22-Oct-08,
<draft-ietf-smime-3278bis-03.txt>
This document describes how to use Elliptic Curve Cryptography (ECC)
public-key algorithms in the Cryptographic Message Syntax (CMS). The
ECC algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate content. The definition of
the algorithm processing is based on the NIST FIPS 186-3 for digital signature,
NIST SP800-56A for key agreement, RFC 3565 and RFC 3370 for key wrap and
content encryption, NIST FIPS 180-3 for message digest, and RFC 2104 and
RFC 4231 for message authentication code standards. This document will obsolete
RFC 3278.
Softwires (softwire)
--------------------
"Softwire Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, Carlos
Pignataro, Maria Santos, Bruno Stevant, Jean-Francois Tremblay, 29-Oct-08,
<draft-ietf-softwire-hs-framework-l2tpv2-10.txt>
This document describes the framework of the Softwire "Hub and Spoke"
solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The
implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations.
"Softwire Security Analysis and Requirements", Shu Yamamoto, Carl Williams,
Florent Parent, Hidetoshi Yokota, 27-Oct-08,
<draft-ietf-softwire-security-requirements-06.txt>
This document describes the security guidelines for the softwire
"Hubs and Spokes" and "Mesh" solutions. Together with the discussion
of the softwire deployment scenarios, the vulnerability to the
security attacks is analyzed to provide the security protection
mechanism such as authentication, integrity and confidentiality to
the softwire control and data packets.
"Softwire Mesh Framework", Jianping Wu, Yong Cui, Xing Li, Chris Metz, Eric
Rosen, Simon Barber, Pradosh Mohapatra, John Scudder, Intellectual Property,
18-Sep-08, <draft-ietf-softwire-mesh-framework-05.txt>
The Internet needs to be able to handle both IPv4 and IPv6 packets.
However, it is expected that some constituent networks of the
Internet will be "single protocol" networks. One kind of single
protocol network can parse only IPv4 packets and can process only
IPv4 routing information; another kind can parse only IPv6 packets
and can process only IPv6 routing information. It is nevertheless
required that either kind of single protocol network be able to
provide transit service for the "other" protocol. This is done by
passing the "other kind" of routing information from one edge of the
single protocol network to the other, and by tunneling the "other
kind" of data packet from one edge to the other. The tunnels are
known as "Softwires". This framework document explains how the
routing information and the data packets of one protocol are passed
through a single protocol network of the other protocol. The
document is careful to specify when this can be done with existing
technology, and when it requires the development of new or modified
technology.
"Advertising an IPv4 NLRI with an IPv6 Next Hop", Francois Le Faucheur, Eric
Rosen, 27-Oct-08, <draft-ietf-softwire-v4nlri-v6nh-01.txt>
MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer
protocols to which the address carried in the Next Hop field may
belong is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The current AFI/SAFI
definitions for the IPv4 address family only have provisions for
advertising a Next Hop address that belongs to the IPv4 protocol when
advertising an IPv4 Network Layer Reachability Information (NLRI) or
a VPN-IPv4 NLRI. This document specifies the extensions necessary to
allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop
address that belongs to the IPv6 protocol. This comprises an
extension of the AFI/SAFI definitions to allow the address of the
Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6
protocol, the encoding of the Next Hop in order to determine which of
the protocols the address actually belongs to, and a new BGP
Capability allowing MP-BGP Peers to dynamically discover whether they
can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
"BGP Traffic Engineering Attribute", Don Fedyk, Yakov Rekhter, Hamid
Ould-Brahim, 10-Sep-08, <draft-ietf-softwire-bgp-te-attribute-03.txt>
This document defines a new BGP attribute, Traffic Engineering
attribute, than enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its
use for non-VPN reachability information.
"BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", Pradosh
Mohapatra, Eric Rosen, Intellectual Property, 4-Jun-08,
<draft-ietf-softwire-encaps-safi-03.txt>
In certain situations, transporting a packet from one Border Gateway
Protocol (BGP) speaker to another, the BGP next hop, requires that
the packet be encapsulated by the first BGP speaker and decapsulated
by the second. To support these situations, there needs to be some
agreement between the two BGP speakers with regard to the
"encapsulation information", i.e., the format of the encapsulation
header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all
encapsulation types. In the cases where the signaling is required
(such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic
Routing Encapsulation (GRE) with key), this draft specifies a method
by which BGP speakers can signal encapsulation information to each
other. The signaling is done by sending BGP updates using the
"Encapsulation Subsequent Address Family Identifier (SAFI)" and IPv4
or IPv6 Address Family Identifier (AFI). In the cases where no
encapsulation information needs to be signaled (such as GRE without
key), this draft specifies a BGP extended community that can be
attached to BGP UPDATE messages that carry payload prefixes to
indicate the encapsulation protocol type to be used.
"BGP IPSec Tunnel Encapsulation Attribute", Lou Berger, Russ White, Eric
Rosen, 1-May-08, <draft-ietf-softwire-encaps-ipsec-01.txt>
The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
provides a method for the dynamic exchange of encapsulation
information, and the indication of encapsulation protocol types to be
used for different next hops. Currently support for GRE and L2TPv3
tunnel types are defined. This document defines support for IPsec
tunnel types.
Speech Services Control (speechsc)
----------------------------------
"Media Resource Control Protocol Version 2 (MRCPv2)", Saravanan Shanmugham,
Daniel Burnett, 3-Nov-08, <draft-ietf-speechsc-mrcpv2-17.txt>
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 a session management protocol
such as the Session Initiation Protocol (SIP) to establish the MRCPv2
control session between the client and the server, and for rendezvous
and capability discovery. 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.
Session PEERing for Multimedia INTerconnect (speermint)
-------------------------------------------------------
"SPEERMINT Terminology", Daryl Malas, Dave Meyer, 18-Nov-08,
<draft-ietf-speermint-terminology-17.txt>
This document defines the terminology that is to be used in
describing Session PEERing for Multimedia INTerconnect (SPEERMINT).
"SPEERMINT Requirements for SIP-based Session Peering", Jean-Francois Mule,
17-Oct-08, <draft-ietf-speermint-requirements-07.txt>
This memo captures protocol requirements to enable session peering of
voice, presence, instant messaging and other types of multimedia
traffic. It is based on the use cases that have been described in
the SPEERMINT working group. This informational document is intended
to link the session peering use cases to protocol solutions.
"SPEERMINT Peering Architecture", Sohel Khan, 3-Nov-08,
<draft-ietf-speermint-architecture-07.txt>
This document defines the SPEERMINT peering architecture, its
functional components and peering interface functions. It also
describes the steps taken to establish a session between two peering
domains in the context of the functions defined.
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[1]
"SPEERMINT Routing Architecture Message Flows", Hadriel Kaplan, Daryl Malas,
Sohel Khan, Reinaldo Penno, Adam Uzelac, 3-Nov-08,
<draft-ietf-speermint-flows-04.txt>
This document describes example message flows associated with the
SPEERMINT routing architecture, relative to various peering
scenarios.
"Use of DNS SRV and NAPTR Records for SPEERMINT", Tom Creighton, Jason
Livingood, 20-Nov-08, <draft-ietf-speermint-srv-naptr-use-04.txt>
The objective of this document is to specify the Best Current
Practice (BCP) adopted by a service provider providing multimedia
communication services such as Voice over Internet Protocol(VoIP) in
order to locate another service provider to peer with in the context
of Session PEERing for Multimedia INTerconnect.
"VoIP SIP Peering Use Cases", Adam Uzelac, Yiu Lee, 17-Nov-08,
<draft-ietf-speermint-voip-consolidated-usecases-11.txt>
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.
"SPEERMINT Security Threats and Suggested Countermeasures", Saverio
Niccolini, Eric Chen, Jan Seedorf, Hendrik Scholz, 17-Nov-08,
<draft-ietf-speermint-voipthreats-00.txt>
This memo presents the different security threats related to
SPEERMINT classifying them into threats to the Location Function, to
the Signaling Function and to the Media Function. The different
instances of the threats are briefly introduced inside the
classification. Finally the existing security solutions in SIP and
RTP/RTCP are presented to describe the countermeasures currently
available for such threats. The objective of this document is to
identify and enumerate the SPEERMINT-specific threat vectors in order
to specify security-related requirements. Once the requirements are
identified, methods and solutions how to achieve such requirements
can be selected.
Security Issues in Network Event Logging (syslog)
-------------------------------------------------
"Signed syslog Messages", John Kelsey, 4-Oct-07,
<draft-ietf-syslog-sign-23.txt>
This document describes a mechanism to add origin authentication,
message integrity, replay resistance, message sequencing, and
detection of missing messages to the transmitted syslog messages.
This specification is intended to be used in conjunction with the
work defined in RFC xxxx, "The syslog Protocol".
"The syslog Protocol", Rainer Gerhards, 6-Sep-07,
<draft-ietf-syslog-protocol-23.txt>
This document describes the syslog protocol, which is used to convey
event notification messages. This protocol utilizes a layered
architecture, which allows the use of any number of transport
protocols for transmission of syslog messages. It also provides a
message format that allows vendor-specific extensions to be provided
in a structured way.
This document has been written with the original design goals for
traditional syslog in mind. The reason for a new layered
specification has arisen because standardization efforts for reliable
and secure syslog extensions suffer from the lack of a standards-
track and transport independent RFC. Without this document, each
other standard needs to define its own syslog packet format and
transport mechanism, which over time will introduce subtle
compatibility issues. This document tries to provide a foundation
that syslog extensions can build on. This layered architecture
approach also provides a solid basis that allows code to be written
once for each syslog feature rather than once for each transport.
This document obsoletes RFC3164.
"Transmission of syslog messages over UDP", Anton Okmianski, 5-Sep-07,
<draft-ietf-syslog-transport-udp-12.txt>
This document describes the transport for syslog messages over UDP/
IPv4 or UDP/IPv6. The syslog protocol layered architecture provides
for support of any number of transport mappings. However, for
interoperability purposes, syslog protocol implementers are required
to support this transport mapping.
"TLS Transport Mapping for Syslog", Miao Fuyou, Ma Yuzhi, Joseph Salowey,
1-Oct-08, <draft-ietf-syslog-transport-tls-14.txt>
This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.
"Textual Conventions for Syslog Management", Glenn Mansfield, 22-May-08,
<draft-ietf-syslog-tc-mib-08.txt>
This MIB module defines textual conventions to represent
Facility and Severity information commonly used in syslog messages.
The intent is that these textual conventions will be imported and
used in MIB modules that would otherwise define their own
representations.
TCP Maintenance and Minor Extensions (tcpm)
-------------------------------------------
"Improving TCP's Robustness to Blind In-Window Attacks", Anantha Ramaiah,
Randall Stewart, Mitesh Dalal, 2-Nov-08, <draft-ietf-tcpm-tcpsecure-11.txt>
TCP has historically been considered protected against spoofed off-
path packet injection attacks by relying on the fact that it is
difficult to guess the 4-tuple (the source and destination IP
addresses and the source and destination ports) in combination with
the 32 bit sequence number(s). A combination of increasing window
sizes and applications using longer term connections (e.g. H-323 or
Border Gateway Protocol [RFC4271]) have left modern TCP
implementations more vulnerable to these types of spoofed packet
injection attacks.
Many of these long term TCP applications tend to have predictable IP
addresses and ports which makes it far easier for the 4-tuple
(4-tuple is the same as the socket pair mentioned in [RFC0793]) to be
guessed. Having guessed the 4-tuple correctly, an attacker can
inject a TCP segment with the RST bit set, the SYN bit set or data
into a TCP connection by systematically guessing the sequence number
of the spoofed segment to be in the current receive window. This can
cause the connection to abort or cause data corruption. This
document specifies small modifications to the way TCP handles inbound
segments that can reduce the chances of a successful attack.
"TCP User Timeout Option", Lars Eggert, Fernando Gont, 13-Jun-08,
<draft-ietf-tcpm-tcp-uto-09.txt>
The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed. It is a
local, per-connection parameter. This document specifies a new TCP
option - the TCP User Timeout Option - that allows one end of a TCP
connection to advertise its current user timeout value. This
information provides advice to the other end of the TCP connection to
adapt its user timeout accordingly. Increasing the user timeouts on
both ends of a TCP connection allows it to survive extended periods
without end-to-end connectivity. Decreasing the user timeouts allows
busy servers to explicitly notify their clients that they will
maintain the connection state only for a short time without
connectivity.
"Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK
Packets", Sally Floyd, Intellectual Property, 3-Nov-08,
<draft-ietf-tcpm-ecnsyn-07.txt,.ps>
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting
an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK
packets. However, because of the high cost to the TCP transfer of
having a SYN/ACK packet dropped, with the resulting retransmit
timeout, this document specifies the use of ECN for the SYN/ACK
packet itself, when sent in response to a SYN packet with the two ECN
flags set in the TCP header, indicating a willingness to use ECN.
Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great
benefit to the TCP connection, avoiding the severe penalty of a
retransmit timeout for a connection that has not yet started placing
a load on the network. The TCP responder (the sender of the SYN/ACK
packet) must reply to a report of an ECN-marked SYN/ACK packet by
resending a SYN/ACK packet that is not ECN-Capable. If the resent
SYN/ACK packet is acknowledged, then the TCP responder reduces its
initial congestion window from two, three, or four segments to one
segment, thereby reducing the subsequent load from that connection on
the network. If instead the SYN/ACK packet is dropped, or for some
other reason the TCP responder does not receive an acknowledgement in
the specified time, the TCP responder follows TCP standards for a
dropped SYN/ACK packet (setting the retransmit timer). This document
updates RFC 3168.
"TCP's Reaction to Soft Errors", Fernando Gont, 23-Apr-08,
<draft-ietf-tcpm-tcp-soft-errors-08.txt>
This document describes a non-standard, but widely implemented,
modification to TCP's handling of ICMP soft error messages, that
rejects pending connection-requests when those error messages are
received. This behavior reduces the likelihood of long delays
between connection establishment attempts that may arise in a number
of scenarios, including one in which dual stack nodes that have IPv6
enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
environments.
"ICMP attacks against TCP", Fernando Gont, 27-Oct-08,
<draft-ietf-tcpm-icmp-attacks-04.txt>
This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols.
Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these
issues.
"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious
Retransmission Timeouts with TCP", Pasi Sarolahti, Markku Kojo, Kazunori
Yamamoto, Max Hata, Intellectual Property, 30-Oct-08,
<draft-ietf-tcpm-rfc4138bis-04.txt>
The purpose of this document is to move the F-RTO functionality for
TCP in RFC 4138 from Experimental to Standards Track status. The F-
RTO support for SCTP in RFC 4138 remains with Experimental status.
See Appendix B for the differences between this document and RFC
4138.
Spurious retransmission timeouts cause suboptimal TCP performance
because they often result in unnecessary retransmission of the last
window of data. This document describes the F-RTO detection
algorithm for detecting spurious TCP retransmission timeouts. F-RTO
is a TCP sender-only algorithm that does not require any TCP options
to operate. After retransmitting the first unacknowledged segment
triggered by a timeout, the F-RTO algorithm of the TCP sender
monitors the incoming acknowledgments to determine whether the
timeout was spurious. It then decides whether to send new segments
or retransmit unacknowledged segments. The algorithm effectively
helps to avoid additional unnecessary retransmissions and thereby
improves TCP performance in the case of a spurious timeout.
"The TCP Authentication Option", Joseph Touch, Allison Mankin, Ronald Bonica,
3-Nov-08, <draft-ietf-tcpm-tcp-auth-opt-02.txt>
This document specifies the TCP Authentication Option (TCP-AO), which
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
specifies the use of stronger Message Authentication Codes (MACs),
protects against replays even for long-lived TCP connections, and
provides more details on the association of security with TCP
connections than TCP MD5. TCP-AO is compatible with either static
keying or an external, out-of-band key management mechanism; in
either case, TCP-AO also protects connections when using the same key
across repeated instances of a connection. The result is intended to
support current infrastructure uses of TCP MD5, such as to protect
long-lived connections (as used, e.g., in BGP and LDP), and to
support a larger set of MACs with minimal other system and
operational changes. TCP-AO uses its own option identifier, even
though used mutually exclusive of TCP MD5 on a given TCP connection.
TCP-AO supports IPv6, and is fully compatible with the requirements
for the replacement of TCP MD5.
"Early Retransmit for TCP and SCTP", Mark Allman, Konstantin Avrachenkov,
Urtzi Ayesta, Ethan Blanton, Per Hurtig, 28-Aug-08,
<draft-ietf-tcpm-early-rexmt-00.txt>
This document proposes a new mechanism for TCP and SCTP that can be
used to recover lost segments when a connection's congestion window
is small. The "Early Retransmit" mechanism allows the transport to
reduce, in certain special circumstances, the number of duplicate
acknowledgments required to trigger a fast retransmission. This
allows the transport to use fast retransmit to recover packet losses
that would otherwise require a lengthy retransmission timeout.
Timing over IP Connection and Transfer of Clock (tictoc)
--------------------------------------------------------
"Architecture for the Transmission of Timing over Packet Networks", Tim
Frost, Greg Dowd, Intellectual Property, 3-Nov-08,
<draft-stein-tictoc-modules-03.txt>
This Internet draft proposes an architecture for the transmission of
timing over packet networks. It identifies the major functional
components, and maps the current solutions onto this framework.
Transport Layer Security (tls)
------------------------------
"Transport Layer Security (TLS) Extensions: Extension Definitions", Donald
Eastlake 3rd, 5-Oct-08, <draft-ietf-tls-rfc4366-bis-03.txt>
This document provides documentation for existing specific TLS
extensions. It is a companion document for the TLS 1.2 specification
[RFC5246]. The extensions specified are server_name,
max_fragment_length, client_certificate_url, trusted_ca_keys,
truncated_hmac, and status_request.
"Keying Material Extractors for Transport Layer Security (TLS)", Eric
Rescorla, 2-Nov-08, <draft-ietf-tls-extractor-03.txt>
A number of protocols wish to leverage Transport Layer Security (TLS)
to perform key establishment but then use some of the keying material
for their own purposes. This document describes a general mechanism
for allowing that.
"ECDHE_PSK Ciphersuites for Transport Layer Security (TLS)", Mohamad Badra,
31-Oct-08, <draft-ietf-tls-ecdhe-psk-05.txt>
This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies
a set of cipher suites that use a pre-shared key (PSK) to
authenticate an Elliptic Curve Diffie-Hellman exchange (ECDH). These
cipher suites provide Perfect Forward Secrecy (PFS).
"DES and IDEA Cipher Suites for Transport Layer Security (TLS)", Pasi Eronen,
25-Jun-08, <draft-ietf-tls-des-idea-02.txt>
TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included
cipher suites based on DES (Data Encryption Standard) and IDEA
(International Data Encryption Algorithm) algorithms. DES (when used
in single-DES mode) and IDEA are no longer recommended for general
use in TLS, and have been removed from TLS 1.2 main specification
(RFC 5246). This document specifies these cipher suites for
completeness, and discusses reasons why their use is no longer
recommended.
"Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with
SHA-256/384 and AES Galois Counter Mode", Mohamad Badra, 30-Oct-08,
<draft-ietf-tls-psk-new-mac-aes-gcm-05.txt>
RFC 4279 and RFC 4785 describe pre-shared key cipher suites for
Transport Layer Security (TLS). However, all those cipher suites
use SHA-1 as their MAC algorithm. This document describes a set of
pre-shared key cipher suites for TLS which uses stronger digest
algorithms (i.e., SHA-256 or SHA-384) and another set which uses the
Advanced Encryption Standard (AES) in Galois Counter Mode (GCM).
"Datagram Transport Layer Security version 1.2", Eric Rescorla, Nagendra
Modadugu, 1-Nov-08, <draft-ietf-tls-rfc4347-bis-01.txt>
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.
Transparent Interconnection of Lots of Links (trill)
----------------------------------------------------
"Rbridges: Base Protocol Specification", Radia Perlman, 3-Nov-08,
<draft-ietf-trill-rbridge-protocol-10.txt>
RBridges provide optimal pair-wise forwarding with zero
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 forwarding tables to be sized according to
the number of RBridges (rather than the number of end nodes), which
allows internal forwarding tables to be substantially smaller than in
conventional bridges.
"Transparent Interconnection of Lots of Links (TRILL): Problem and
Applicability Statement", Joseph Touch, Radia Perlman, 29-Sep-08,
<draft-ietf-trill-prob-05.txt>
Current Ethernet (802.1) link layers use spanning tree protocols that
have a number of challenges. These protocols need to strictly avoid
loops, even temporary ones, during route propagation, because of the
lack of header loop detection support. Routing tends not to take full
advantage of alternate paths, or even non-overlapping pairwise paths
(in the case of spanning trees). This document addresses these
concerns and suggests that they can be addressed by applying modern
network layer routing protocols at the link layer. This document
assumes that solutions would not address issues of scalability beyond
that of existing bridged (802.1) links, but that a solution would be
backward compatible with 802.1, including hubs, bridges, and their
existing plug-and-play capabilities.
Transport Area Working Group (tsvwg)
------------------------------------
"Sockets API Extensions for Stream Control Transmission Protocol (SCTP)",
Randall Stewart, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, Peter
Lei, 3-Nov-08, <draft-ietf-tsvwg-sctpsocket-18.txt>
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.
"Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services",
Francois Le Faucheur, James Polk, Ken Carlberg, 17-Oct-08,
<draft-ietf-tsvwg-emergency-rsvp-09.txt>
An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis). When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they 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. Note that these extensions
represent one possible solution component in satisfying ETS
requirements. Other solution components, or other solutions, are
outside the scope of this document.
The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set
of administrative domains that closely coordinate their network
policy and network design. The mechanisms defined in this document
can be used for a session whose path spans over such a controlled
environment in order to elevate the session establishment probability
through the controlled environment (thereby elevating the end to end
session establishment probability).
"DSCP for Capacity-Admitted Traffic", Fred Baker, James Polk, Martin Dolly,
2-Nov-08, <draft-ietf-tsvwg-admitted-realtime-dscp-05.txt>
This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for real-time
traffic classes similar to voice conforming to the Expedited
Forwarding Per Hop Behavior, and admitted using a call admission
procedure involving authentication, authorization, and capacity
admission.
This document also recommends that certain classes of video traffic
described in RFC 4594 and which have similar requirements be changed
to require admission using a Call Admission Control (CAC) procedure
involving authentication, authorization, and capacity admission.
"RSVP Extensions for Path-Triggered RSVP Receiver Proxy", Francois Le
Faucheur, Jukka Manner, Ashok Narayanan, Allan Guillou, Le Faucheur,
1-Jul-08, <draft-ietf-tsvwg-rsvp-proxy-proto-07.txt>
RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of
a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
thereby performing RSVP signaling on behalf of the receiver. This
allows resource reservations to be established on the segment of the
end-to-end path from the sender to the RSVP Receiver Proxy. However,
as discussed in the companion document presenting RSVP Proxy
approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these
extensions.
"RSVP Proxy Approaches", Francois Le Faucheur, Jukka Manner, Dan Wing, Allan
Guillou, 31-Oct-08, <draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt>
The Resource ReSerVation Protocol (RSVP) can be used to make end-to-
end resource reservations in an IP network in order to guarantee the
quality of service required by certain flows. RSVP assumes that both
the data sender and receiver of a given flow take part in RSVP
signaling. Yet, there are many use cases where resource reservation
is required, but the receiver, the sender, or both, is not RSVP-
capable. This document presents RSVP Proxy behaviors allowing RSVP
routers to initiate or terminate RSVP signaling on behalf of a
receiver or a sender that is not RSVP-capable. This allows resource
reservations to be established on a critical subset of the end-to-end
path. This document reviews conceptual approaches for deploying RSVP
Proxies and discusses how RSVP reservations can be synchronized with
application requirements, despite the sender, receiver, or both not
participating in RSVP. This document also points out where
extensions to RSVP (or to other protocols) may be needed for
deployment of a given RSVP Proxy approach. However, such extensions
are outside the scope of this document. Finally, practical use cases
for RSVP Proxy are described.
"Port Randomization", Michael Larsen, Fernando Gont, 31-Aug-08,
<draft-ietf-tsvwg-port-randomization-02.txt>
Recently, awareness has been raised about a number of "blind" attacks
that can be performed against the Transmission Control Protocol (TCP)
and similar protocols. The consequences of these attacks range from
throughput-reduction to broken connections or data corruption. These
attacks rely on the attacker's ability to guess or know the five-
tuple (Protocol, Source Address, Destination Address, Source Port,
Destination Port) that identifies the transport protocol instance to
be attacked. This document describes a number of simple and
efficient methods for the random selection of the client port number,
such that the possibility of an attacker guessing the exact value is
reduced. While this is not a replacement for cryptographic methods,
the described port number randomization algorithms provide improved
security/obfuscation with very little effort and without any key
management overhead. The algorithms described in this document are
local policies that may be incrementally deployed, and that do not
violate the specifications of any of the transport protocols that may
benefit from them, such as TCP, UDP, UDP-lite, SCTP, DCCP, and RTP.
"Applicability of Keying Methods for RSVP Security", Michael Behringer,
Francois Le Faucheur, 3-Nov-08,
<draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt>
The Resource reSerVation Protocol (RSVP) allows hop-by-hop
authentication of RSVP neighbors. This requires messages to be
cryptographically signed 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 present document also discusses applicability
of group keying to RSVP encryption.
"Support for RSVP in Layer 3 VPNs", Bruce Davie, Francois Le Faucheur, Ashok
Narayanan, 1-Nov-08, <draft-ietf-tsvwg-rsvp-l3vpn-01.txt>
RFC 4364 and RFC 4659 define an approach to building provider-
provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to
use RSVP to perform admission control on the links between CE and PE
routers. This document specifies procedures by which RSVP messages
travelling from CE to CE across an L3VPN may be appropriately handled
by PE routers so that admission control can be performed on PE-CE
links. Optionally, admission control across the provider's backbone
may also be supported.
"IANA Procedures for the Transport Protocol Port Number Space", Michelle
Cotton, Lars Eggert, Allison Mankin, Magnus Westerlund, Joseph Touch,
3-Nov-08, <draft-ietf-tsvwg-iana-ports-01.txt>
This document defines the IANA procedures for registering port number
values for use with the various IETF transport protocols, including
TCP, UDP, DCCP, and SCTP. It provides clear procedures for the
management of the port number registry, which is important for its
long-term management. It updates RFC2780 by obsoleting Sections 8
and 9.1 of that RFC, and it updates the IANA allocation procedures
for DCCP as defined in RFC4340.
"Byte and Packet Congestion Notification", Bob Briscoe, 7-Aug-08,
<draft-ietf-tsvwg-byte-pkt-congest-00.txt>
This memo concerns dropping or marking packets using active queue
management (AQM) such as random early detection (RED) or pre-
congestion notification (PCN). The primary conclusion is that packet
size should be taken into account when transports read congestion
indications, not when network equipment writes them. Reducing drop
of small packets has some tempting advantages: i) it drops less
control packets, which tend to be small and ii) it makes TCP's bit-
rate less dependent on packet size. However, there are ways of
addressing these issues at the transport layer, rather than reverse
engineering network forwarding to fix specific transport problems.
Network layer algorithms like the byte-mode packet drop variant of
RED should not be used to drop fewer small packets, because that
creates a perverse incentive for transports to use tiny segments,
consequently also opening up a DoS vulnerability.
"Layered Encapsulation of Congestion Notification", Bob Briscoe, 27-Oct-08,
<draft-ietf-tsvwg-ecn-tunnel-01.txt>
This document redefines how the explicit congestion notification
(ECN) field of the outer IP header of a tunnel should be constructed.
It brings all IP in IP tunnels (v4 or v6) into line with the way
IPsec tunnels now construct the ECN field. It includes a thorough
analysis of the reasoning for this change and the implications. It
also gives guidelines on the encapsulation of IP congestion
notification by any outer header, whether encapsulated in an IP
tunnel or in a lower layer header. Following these guidelines should
help interworking, if the IETF or other standards bodies specify any
new encapsulation of congestion notification.
"Datagram Transport Layer Security for Stream Control Transmission Protocol",
Michael Tuexen, Robin Seggelmann, Eric Rescorla, 22-Oct-08,
<draft-ietf-tsvwg-dtls-for-sctp-00.txt>
This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol over the Stream Control Transmission
Protocol (SCTP).
The user of DTLS over SCTP can take advantage of all features
provided by SCTP and its extensions, especially support of
o multiple streams to avoid head of line blocking.
o multi-homing to provide network level fault tolerance.
o unordered delivery.
o partially reliable data transfer.
Usenet Article Standard Update (usefor)
---------------------------------------
"Netnews Article Format", Charles Lindsey, 9-Jan-07,
<draft-ietf-usefor-usefor-12.txt>
This document specifies the syntax of Netnews articles in the context
of the "Internet Message Format" (RFC 2822) and "Multipurpose
Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes
RFC 1036, providing an updated specification to reflect current
practice and incorporating incremental changes specified in other
documents.
"Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey,
27-Aug-08, <draft-ietf-usefor-usepro-12.txt>
This document defines the architecture of Netnews systems and
specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and
displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles.Internet Draft
Comments
Comments are solicited and should be addressed to the Usenet Format
Working Group at ietf-usefor@imc.org.
IPv6 Operations (v6ops)
-----------------------
"IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, Chip
Popoviciu, Tim Chown, Olaf Bonness, Christian Hahn, 22-Sep-08,
<draft-ietf-v6ops-addcon-10.txt>
One fundamental aspect of any IP communications infrastructure is its
addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing. Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of
IPv6. This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments. The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network.
"Recommended Simple Security Capabilities in Customer Premises Equipment for
Providing Residential IPv6 Internet Service", James Woodyatt, 29-Jul-08,
<draft-ietf-v6ops-cpe-simple-security-03.txt>
This document makes specific recommendations to the makers of devices
that provide "simple security" capabilities at the perimeter of
local-area IPv6 networks in Internet-enabled homes and small offices.
"IPv6 RA-Guard", Eric Levy-Abegnoli, Gunter Van de Velde, Chip Popoviciu,
Janos Mohacsi, 10-Sep-08, <draft-ietf-v6ops-ra-guard-01.txt>
It is particularly easy to experience "rogue" routers on an unsecured
link. Devices acting as a rougue router may send illegitimate RAs.
Section 6 of SeND [RFC3971] provides a full solution to this problem,
by enabling routers certification. This solution does, however,
require all nodes on an L2 network segment to support SeND, as well
as it carries some deployment challenges. End-nodes must be
provisioned with certificate anchors. The solution works better when
end-nodes have access to a Certificate Revocation List server, and to
a Network Time Protocol server, both typically off-link, which brings
some bootstrap issues.
When using IPv6 within a single L2 network segment it is possible and
sometimes desirable to enable layer 2 devices to drop rogue RAs
before they reach end-nodes. In order to distinguish valid from
rogue RAs, the L2 devices can use a spectrum of criterias, from a
static scheme that blocks RAs received on un-trusted ports, or from
un-trusted sources, to a more dynamic scheme that uses SeND to
challenge RA sources.
This document reviews various techniques applicable on the L2 devices
to reduce the threat of rogue RAs.
"Security Concerns With IP Tunneling", James Hoagland, Suresh Krishnan, Dave
Thaler, 14-Oct-08, <draft-ietf-v6ops-tunnel-security-concerns-01.txt>
A number of security concerns with IP tunnels are documented in this
document. The intended audience of this document includes network
administrators and future protocol developers. The primary intent of
this document is to raise the awareness regarding the security issues
with IP tunnels as deployed today.
vCard and CardDAV (vcarddav)
----------------------------
"vCard Format Specification", Simon Perreault, Pete Resnick, 3-Nov-08,
<draft-ietf-vcarddav-vcardrev-05.txt>
This document defines the vCard data format for representing and
exchanging a variety of information about an individual (e.g.,
formatted and structured name and delivery addresses, email address,
multiple telephone numbers, photograph, logo, audio clips, etc.).
"vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 12-Jul-08,
<draft-ietf-vcarddav-carddav-01.txt>
This document defines extensions to the Web Distributed Authoring and
Versioning (WebDAV) protocol to specify a standard way of accessing,
managing, and sharing contact information based on the vCard format.
Discussion of this Internet-Draft is taking place on the mailing list
<http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>.
Virtual Router Redundancy Protocol (vrrp)
-----------------------------------------
"Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6", Stephen
Nadas, 15-Apr-08, <draft-ietf-vrrp-unified-spec-02.txt>
This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv4 and IPv6. It is version three (3) of the protocol and it is
based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on
draft-ieft-vrrp-ipv6-spec-08.txt. VRRP specifies an election
protocol that dynamically assigns responsibility for a virtual router
to one of the VRRP routers on a LAN. The VRRP router controlling the
IPv4 or IPv6 address(es) associated with a virtual router is called
the Master, and forwards packets sent to these IPv4 or IPv6
addresses. VRRP Master routers are configured with virtual IPv4 or
IPv6 addresses and VRRP Backup routers infer the address family of
the virtual addresses being carried based on the transport protocol.
Within a VRRP router the virtual routers in each of the IPv4 and IPv6
address families are a domain unto themselves and do not overlap.
The election process provides dynamic fail over in the forwarding
responsibility should the Master become unavailable. For IPv4, the
advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router
discovery protocols on every end-host. For IPv6, the advantage
gained from using VRRP for IPv6 is a quicker switch over to back up
routers than can be obtained with standard IPv6 Neighbor Discover
(RFC 4861) mechanisms.
WWW Distributed Authoring and Versioning (webdav)
-------------------------------------------------
"Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)",
Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead, 28-Oct-08,
<draft-ietf-webdav-bind-22.txt>
This specification defines bindings, and the BIND method for creating
multiple bindings to the same resource. Creating a new binding to a
resource causes at least one new URI to be mapped to that resource.
Servers are required to insure the integrity of any bindings that
they allow to be created.Editorial Note (To be removed by RFC Editor before
publication)
Please send comments to the Distributed Authoring and Versioning
(WebDAV) working group at <mailto:w3c-dist-auth@w3.org>, which may be
joined by sending a message with subject "subscribe" to
<mailto:w3c-dist-auth-request@w3.org>. Discussions of the WEBDAV
working group are archived at
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
<http://www.webdav.org/bind/draft-ietf-webdav-bind-issues.html> lists
all registered issues since draft 02.
Centralized Conferencing (xcon)
-------------------------------
"Conference Information Data Model for Centralized Conferencing (XCON)",
Oscar Novo, Gonzalo Camarillo, David Morgan, Roni Even, Jari Urpalainen,
28-Oct-08, <draft-ietf-xcon-common-data-model-12.txt>
This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing
(XCON). A conference information data model is designed to convey
information about the conference and about participation in the
conference. The conference information data model defined in this
document constitutes an extension of the data format specified in the
Session Initiation Protocol (SIP) Event Package for Conference State.
"Conference Event Package Data Format Extension for Centralized Conferencing
(XCON)", Gonzalo Camarillo, Srivatsa Srinivasan, Roni Even, Jari Urpalainen,
3-Sep-08, <draft-ietf-xcon-event-package-01.txt>
This document specifies the notification mechanism for XCON
(centralized conferencing). This mechanism reuses the SIP (Session
Initiation Protocol) event package for conference state.
Additionally, the notification mechanism includes support for the
XCON data model and for partial notifications.
"Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton,
Simon Romano, Henning Schulzrinne, 3-Nov-08, <draft-ietf-xcon-ccmp-01.txt>
The Centralized Conferencing Manipulation Protocol (CCMP) can create,
retrieve, change and delete objects describing a centralized
conference, such as state and capabilities of the conference,
participants, and their roles. The conference information is
contained in XML documents and fragments conforming to the
centralized conferencing data model schema. CCMP is a state-less
client-server protocol based on a request/response model.
Conferencing clients send requests to conference servers, which
respond to the client with the conference information.
This document also discusses options for using existing notification
protocols to inform conference client about the changes in the state
of a conference during its entire lifetime.