Network Working Group K. Weniger
Internet-Draft Panasonic
Expires: August 21, 2006 February 17, 2006
PDAD-OLSR: Passive Duplicate Address Detection for OLSR
draft-weniger-autoconf-pdad-olsr-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft proposes PDAD-OLSR, a solution for configured address
uniqueness maintenance in MANETs running the OLSR protocol. It
utilizes the Passive Duplicate Address Detection (PDAD) concept,
which enables nodes to passively detect duplicate addresses in the
network (e.g., occurring after network merging) by analyzing received
routing protocol messages. Due to its passive nature, PDAD-OLSR is
very efficient in terms of bandwidth consumption. Moreover, it can
prevent the contamination of routing tables with wrong routing
information resulting from an address conflict.
Weniger Expires August 21, 2006 [Page 1]
Internet-Draft PDAD February 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Problem Description . . . . . . . . . . . . 4
3. Overview of the Passve DAD concept . . . . . . . . . . . . . 5
4. PDAD Algorithms for OLSR . . . . . . . . . . . . . . . . . . 6
4.1 Data structures and parameters . . . . . . . . . . . . . . 6
4.2 PDAD-Source Address (SA) . . . . . . . . . . . . . . . . . 7
4.3 PDAD-Sequence Numbers (SN) . . . . . . . . . . . . . . . . 7
4.4 PDAD-Sequence Number Difference (SND) . . . . . . . . . . 8
4.5 PDAD-Sequence Numbers Equal (SNE) . . . . . . . . . . . . 8
4.6 PDAD-SNs Always Increment (SNI) . . . . . . . . . . . . . 8
4.7 PDAD-Neighborhood History (NH) . . . . . . . . . . . . . . 8
4.8 PDAD-Link States (LS) . . . . . . . . . . . . . . . . . . 9
4.9 PDAD-extended Neighborhood History (eNH) . . . . . . . . . 9
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . 10
4.11 Detecting sequence number wrap-arounds . . . . . . . . . 11
5. Conflict resolution and related issues . . . . . . . . . . . 12
5.1 Preventing dissemination of false routing information . . 12
5.2 Conflict resolution . . . . . . . . . . . . . . . . . . . 12
5.3 Handling address changes . . . . . . . . . . . . . . . . . 12
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . 13
6.1 PDAD-eNH Hint Message . . . . . . . . . . . . . . . . . . 13
6.2 Conflict Resolution Message . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 17
Weniger Expires August 21, 2006 [Page 2]
Internet-Draft PDAD February 2006
1. Terminology
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 [1].
The terminology of OLSR [2] is used.
Weniger Expires August 21, 2006 [Page 3]
Internet-Draft PDAD February 2006
2. Introduction and Problem Description
Address autoconfiguration is a fundamental issue in MANETs, since
routing protocols assume unique IP addresses in the network and
manual assignment is often not applicable. Solutions for traditional
IP networks such as DHCP [5], DHCPv6 [6], zeroconf [7] or IPv6
Stateless Address Autoconfiguration [8] cannot be applied to MANETs
due to their special properties (see [3] and [10] for an overview of
problems and approaches for MANET address autoconfiguation).
Duplicate Address Detection (DAD) is an essential part of (stateless)
address autoconfiguration. In MANETs, addresses may become duplicate
when they are already assigned to nodes, .e.g, after optimistic
address assignment or after two or more independently configured
MANETs merge to one network. This problem is also referred to as
configured address uniqueness maintenance problem. Not re-using
addresses in different (unconnected) MANETs by constructing IP
addresses based on pre-configured globally unique (hardware) IDs such
as IEEE MAC addresses may solve this problem without DAD, however,
this is not applicable in all scenarios for the following reasons:
o Addresses based on pre-configured globally unique IDs are usually
not 100\% globally unique, e.g., a IEEE MAC address configured at
a specific network interface may be changed by the user, devices
with duplicate MAC addresses exist on the market (non-registered
or erroneous manufacturing), and some devices may not have
globally unique hardware IDs (e.g., sensors)
o Addresses based on pre-configured globally unique IDs may have
negative implications on privacy [4]
o Since this approach requires long addresses (to be able to address
all existing devices), it is only possible with IPv6, not with
IPv4
o Long addresses result in a significant increase of signaling
traffic, e.g., of the routing protocol. Dynamically assigning
locally unique addresses and re-using them in different MANETs is
more efficient, since such addresses may be shorter or can easily
be compressed to short addresses (see [9])
This draft proposes a solution for configured address uniqueness
maintenance in a network running the OLSR protocol [2]. Both IPv4
and IPv6 are supported. The selection and assignment of addresses is
out of scope of this draft. Multiple network interfaces and OLSRv2
are not considered in this version of the draft.
Weniger Expires August 21, 2006 [Page 4]
Internet-Draft PDAD February 2006
3. Overview of the Passve DAD concept
PDAD was first proposed in [11] and later refined and integrated in a
complete address autoconfiguration solution [9]. It defines a set of
rather simple algorithms that allows nodes to detect address
conflicts in the network based on routing protocol anomalies. A
specific combination of algorithms is supposed to to detect all
conflicts in the network running a specific routing protocol. The
basic idea of PDAD is to exploit the fact that some protocol events
occur in case of a duplicate address, but (almost) never in case of a
unique address.
PDAD-enabled nodes derive information about the state of the routing
protocol daemon running on another node and belonging to a specific
address (e.g., address A) from incoming routing protocol messages.
If the node's address equals A, this information is then compared to
the information about the state of the own daemon in order to detect
a possible conflict of the node's own address. If the node's address
does not equal A, it compares the information to information about
the state derived from another recently received routing protocol
message containing this address (address A) in order to detect a
possible conflict of another node's address.
Since the state of a routing protocol daemon is changing over time, a
node receiving a routing protocol message must have information about
the time this routing protocol message has been sent. Without
synchronized clocks and additional information in the messages, this
time can only be estimated. Here, it is assumed that the time
interval during which a specific routing protocol message is
completely disseminated in the network is bounded by the time span
T_D, and that T_D can be estimated. In this case, routing protocol
messages received by a node can never be older than T_D (complete
dissemination of a message does not mean that the message reaches all
nodes, it just means that it is not forwarded anymore in the
network). This assumption holds if the ad hoc routing protocol uses
a duplicate cache, if nodes do not store to be forwarded routing
information for unpredictable time spans and if queuing and media
access delays are bounded. In fact, all well-known ad hoc routing
protocols implicitly assume a certain maximum dissemination time,
since otherwise they would not be able to distinguish fresh from
stale routing information after sequence number wrap-arounds.
Weniger Expires August 21, 2006 [Page 5]
Internet-Draft PDAD February 2006
4. PDAD Algorithms for OLSR
In the following, PDAD algorithms for OLSR are presented. They
utilize different parameters in TC and HELLO messages such as link
states (neighbor interface addresses), link codes and addresses in
routing protocol messages as well as addresses in the IP header. All
of the following algorithms must be applied in combination to enable
the detection of all conflicts in the network.
4.1 Data structures and parameters
In addition to the OLSR data structures (information repositories),
each node conceptually maintains two tables for PDAD: a Last Received
Protocol Messages (LRM) table and a Neighbor History (NH) table.
The Last Received Protocol Messages (LRM) table contains information
about the last TC and HELLO protocol message received from a specific
originator address. It has the following structure:
o Originator Address
o Message Type
o Message Sequence Number
o Neighbor Interface Addresses (with corresponding Link Codes if
HELLO message)
o Receive Time
The Neighbor History (NH) table contains the history of neighboring
node addresses and is build from received HELLO messages. Entries
older than T_D can be deleted. The entries have the following
structure:
o Neighbor Interface Address
o Last time the receiver has selected this neighbor interface
address as MPR
o Last time the receiver has been selected as MPR by this neighbor
interface address
o Receive Time of HELLO message
The following protocol parameters are used:
Weniger Expires August 21, 2006 [Page 6]
Internet-Draft PDAD February 2006
+----------------------+----------------------+---------------------+
| Parameter name | Meaning | Default value |
+----------------------+----------------------+---------------------+
| SN_MAX | Maximum possible | 65535 |
| | sequence number | |
| | value | |
| | | |
| T_D | Maximum time a | 30s |
| | message is | |
| | disseminated in | |
| | network | |
| | | |
| SN_RATE | Maximum rate of | 5 |
| | message sequence | |
| | number | |
| | incrementation | |
+----------------------+----------------------+---------------------+
4.2 PDAD-Source Address (SA)
If a node receives a TC or HELLO message and the source address in
the IP header is equal to the receiver's address, a conflict of this
address is detected. If the message is a HELLO messages, the
originator address can be used instead, since it is equal to the IP
source address.
The assumption behind this algorithm is that the IP source address is
always the address of the last forwarder. This is true for OLSR,
since it uses application-layer forwarding of TC messages. Care must
be taken by implementers that broadcast messages are not duplicated
within the sending node and internally delivered to the IP stack as
received message.
4.3 PDAD-Sequence Numbers (SN)
If a node receives a TC or HELLO message, it compares the originator
address with its own address. If they equal and the sequence number
in the message is lower than the receiver's sequence number, a
conflict of the originator address is detected. However, this
conditions is also true when a sequence number wrap-arounds occurs.
Hence, it must be ensured that this is not the case. A mechanism to
detect a possible sequence number wrap-around is described in section
Section 4.11.
The assumptions behind this algorithm are that sequence numbers are
incremented with a certain maximum rate and that each node only
Weniger Expires August 21, 2006 [Page 7]
Internet-Draft PDAD February 2006
increments its own internal sequence number counter.
4.4 PDAD-Sequence Number Difference (SND)
If a node receives a TC or HELLO message, it compares the sequence
number in the message with the sequence number in the previously
received message with the same message type and from the same
originator address (obtained from its LRM table). If the sequence
number difference is higher than a threshold SNDTHRES, a conflict of
the originator address is detected. SNDTHRES can be computed as
follows: SNDTHRES=(|T_R1-T_R2|+T_D)*SN_RATE with T_R1 and T_R2 the
receive time of message 1 and 2, respectively. Note that the
computation of the sequence number difference must consider wrap-
arounds. This can be achieved by calculating the difference with
min(|SN1-SN2|,SN_MAX-|SN1-SN2|).
4.5 PDAD-Sequence Numbers Equal (SNE)
If an intermediate node receives a TC or HELLO message, it searches
its LRM table for a message with the same message type value and the
same tuple <sequence number, originator address>. If a matching
entry is found, the node compares the neighbor interface addresses in
both messages. A conflict is detected if they differ. Only messages
arriving in the last SN_MAX/SN_RATE-T_D should be considered due to
possible sequence number wrap-arounds.
The assumption behind this algorithm is that the tuple <sequence
number, originator address> uniquely identifies a messages in case of
unique addresses.
4.6 PDAD-SNs Always Increment (SNI)
If a node receives a HELLO message, it compares the sequence number
in the message with the sequence number in the previous HELLO message
from the same originator address. If the sequence number in the new
message is lower, a conflict of the originator address is detected.
Again, sequence number wrap-arounds must be considered. A mechanism
to detect a possible sequence number wrap-arounds is described in
section Section 4.11.
The assumption is that HELLO messages sent by a specific node are
received in the order they are sent (i.e., with increasing sequence
numbers), since they are not forwarded and hence cannot "overtake"
each other.
4.7 PDAD-Neighborhood History (NH)
If a node receives a TC message, it checks whether its own address is
Weniger Expires August 21, 2006 [Page 8]
Internet-Draft PDAD February 2006
part of the neighbor interface addresses in the TC message. If this
is the case and the link code indicates a bidirectional (or
symmetric) link, the node searches the originator address in its NH
table. If it cannot find the address in the table with a receive
time higher than the current time minus T_D, a conflict of the node's
address is detected. Otherwise, the node additionally checks whether
the NH table indicates that the node has selected the found address
as MPR within the last T_D. If this is not the case, a conflict is
detected.
The assumption behind this algorithm is that a TC message only
contains neighbors that have selected the originator address as MPRs.
If all addresses in the network are unique, a node having an address
equal to one of the neighbor interface addresses in a received TC
message must have been a neighbor of the originator address.
4.8 PDAD-Link States (LS)
If a node receives a TC message with its own address as originator
address, it searches in its NH table for each of the neighbor
interface addresses. If at least one address is not found with a
receive time higher than the current time minus T_D, a conflict of
the originator address is detected. If all addresses have been
found, but NH table indicates that the node's address has not been
selected as MPR by the found address within the last T_D, a conflict
is detected.
4.9 PDAD-extended Neighborhood History (eNH)
If a node receives a TC message, it checks for each neighbor
interface addresses in the message if it is a neighbor. This can be
done by checking the OLSR neighborhood or local link information base
or the LRM table. For each found neighbor address, the node searches
in the LRM table for previously received HELLO messages from this
address. For each found HELLO message, it checks whether the
originator address of the TC message is contained in the set of
neighbor interface addresses of the found HELLO message. If this is
not the case, this is a hint for a conflict of the originator address
of the HELLO message. If this is the case, the node additionally
checks the link codes of the respective neighbor interface addresses
in the HELLO message. If they indicate that the originator address
of the TC message has not been selected as MPR within the last T_D by
the originator address of the HELLO message, the node has another
hint for a conflict of the originator address of the HELLO message.
However, the receiver cannot be sure whether a conflict exists or
not, since it is not aware of the NH table of the respective
neighbor. Hence, if a hint for a conflict is detected, it sends an
hint message to the originator address of the respective HELLO
Weniger Expires August 21, 2006 [Page 9]
Internet-Draft PDAD February 2006
message, which then can make the decision based on its NH table. The
format for the hint message is specified in Section 6.
This algorithm is basically the PDAD-NH algorithm executed on behalf
of a neighboring node. Minimal local signaling is needed, which
means that this algorithm is not completely passive. A rate control
mechanism can be implemented to limit the sending rate of hint
messages triggered by a hint about the same possible address
conflict. Furthermore, less signaling is required if each node
additionally stores the neighborhood history of each neighbor.
However, this requires extra amount of memory and hence is optional.
4.10 Summary
This section summarizes the properties of the PDAD algorithms.
+------------+------------+-------------+-------------+-------------+
| Algorithm | Relevant | Potentially | Maximum | Completely |
| | parameters | conflicting | distance | passive |
| | in message | nodes | between | |
| | | | conflicting | |
| | | | nodes | |
+------------+------------+-------------+-------------+-------------+
| PDAD-SA | sequence | originator/ | 1 hop | yes |
| | number, IP | forwarder | | |
| | source | and | | |
| | address | receiver | | |
| | | | | |
| PDAD-SN | sequence | originator | n hops | yes |
| | number, | and | | |
| | originator | receiver | | |
| | address | | | |
| | | | | |
| PDAD-SND | sequence | both | n hops | yes |
| | number, | originators | | |
| | originator | | | |
| | address | | | |
| | | | | |
| PDAD-SNE | sequence | both | n hops | yes |
| | number, | originators | | |
| | originator | | | |
| | address | | | |
| | | | | |
| PDAD-SNI | sequence | both | 2 hops | yes |
| | number, | originators | | |
| | originator | | | |
| | address | | | |
| | | | | |
Weniger Expires August 21, 2006 [Page 10]
Internet-Draft PDAD February 2006
| PDAD-LS | neighbor | originator | n hops | yes |
| | addresses, | and | | |
| | originator | receiver | | |
| | address | | | |
| | | | | |
| PDAD-NH | neighbor | neighbor of | n hops | yes |
| | addresses, | originator | | |
| | originator | and | | |
| | address | receiver | | |
| | | | | |
| PDAD-eNH | neighbor | neighbor of | n hops | no |
| | addresses, | originator | | |
| | originator | and | | |
| | address | neighbor | | |
+------------+------------+-------------+-------------+-------------+
4.11 Detecting sequence number wrap-arounds
Wrap-arounds can occur because of the limited sequence number space.
Wrap-around events are rare if the sequence number space is large.
If unique addresses in the network, a message dissemination time of
T_D, and a constant sequence number increase rate of SN_RATE are
assumed, the maximum difference of the sequence number value from
receiver and sender point of view is SN_THRES=SN_RATE*T_D.
Consequently, a wrap-around can only have occured if the lower
sequence number value s1 is smaller than SN_THRES and the higher
sequence number value s2 is bigger than SN_MAX-SN_THRES+s1. When a
duplicate address is detected based on PDAD-SN or PDAD-SNI, a node
receives routing protocol messages with a sequence number value lower
than its own or lower than the value in a previous message from that
address. Only if the above condition is not true, the node may be
sure that the reason for this event is an address conflict and not a
wrap-around.
Weniger Expires August 21, 2006 [Page 11]
Internet-Draft PDAD February 2006
5. Conflict resolution and related issues
5.1 Preventing dissemination of false routing information
To prevent the dissemination of false routing information emerging
from an address conflict, a routing protocol message indicating an
address conflict should not be forwarded.
5.2 Conflict resolution
If an algorithm detects a conflict of the receivers's address, the
node changes its IP address in order to resolve the conflict. If a
conflict is detected by an intermediate node, this node should send a
conflict resolution message to the conflicting address. The format
for this message is specified in Section 6. One goal of the conflict
resolution should be to minimize the number of address changes in the
network. Hence, only one node should be forced to change its
address. Hence, the conflict resolution messages shall be delivered
to the node that triggered the conflict detection. Therefore, the
destination address is set to the conflicting address and the next
hop should be the last forwarder of the received routing protocol
message that triggered the conflict detection. The latter can be
achieved with the IPv4 loose source routing or the IPv6 routing
header.
5.3 Handling address changes
Care must be taken when a node changes its IP address regarding the
bidirectional link states and the MPR selection, because both are
based on the context of the old address. Hence, a node has to set
all its link states to asymmetric and remove all addresses from its
MPR selector set. Without these modifications, PDAD-NH would
immediately detect a conflict of the new address even if it is
unique.
Weniger Expires August 21, 2006 [Page 12]
Internet-Draft PDAD February 2006
6. Message Formats
6.1 PDAD-eNH Hint Message
The message is encapsulated in an OLSR packet header. The message
format is equal to the TC message format, but has another message
type value (TBD). The IP destination address is set to the
originator address of the received TC message (see Section 4.9).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2 Conflict Resolution Message
The message is encapsulated in an OLSR packet header. The message
only contains the conflicting address. The IP destination address is
set to the conflicting address and a IPv6 routing header or IPv4
loose source option is added, which contains the address of the last
forwarder of the routing protocol message that triggered the conflict
detection. Message type is TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conflicting Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Weniger Expires August 21, 2006 [Page 13]
Internet-Draft PDAD February 2006
7. Security Considerations
TBD
Weniger Expires August 21, 2006 [Page 14]
Internet-Draft PDAD February 2006
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[3] Singh, S., "Ad hoc network autoconfiguration: definition and
problem statement", draft-singh-autoconf-adp-00 (work in
progress), February 2005.
8.2 Informative References
[4] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, March 2005.
[8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[9] Weniger, K., "PACMAN: Passive Autoconfiguration for Mobile Ad
hoc Networks", IEEE Journal of Selected Areas of Communications
(JSAC), Vol. 23 No. 3, March 2005.
[10] Weniger, K., "Address Autoconfiguration in Mobile Ad Hoc
Networks: Current Approaches and Future Directions", IEEE
Network Magazine , July 2004.
[11] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
hoc Networks", IEEE Wireless Communications and Networking
Conference (WCNC), New Orleans, USA, March 2003.
Weniger Expires August 21, 2006 [Page 15]
Internet-Draft PDAD February 2006
Author's Address
Kilian A. Weniger
Panasonic R&D Center Germany
Monzastr. 4c
Langen 63225
Germany
Phone: +49 6103 766 137
Email: kilian.weniger@eu.panasonic.com
Weniger Expires August 21, 2006 [Page 16]
Internet-Draft PDAD February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weniger Expires August 21, 2006 [Page 17]