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