IRTF HIP Research Group                                     T. Henderson
Internet-Draft                                        The Boeing Company
Expires: January 21, 2006                                      A. Gurtov
                                                                    HIIT
                                                           July 20, 2005


                         HIP Experiment Report
                      draft-irtf-hip-experiment-01

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 January 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This is the initial draft of the HIP-RG experiment report.  The
   report summarizes implications of deploying HIP for the end-host
   TCP/IP stack, applications, and network infrastructure.







Henderson & Gurtov      Expires January 21, 2006                [Page 1]


Internet-Draft            HIP Experiment Report                July 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  What is HIP? . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   The ID/Locator Split . . . . . . . . . . . . . . . . . . . .   4
   3.   End-host Stack Implications  . . . . . . . . . . . . . . . .   5
     3.1  Transport issues (CELP, MAST)  . . . . . . . . . . . . . .   5
     3.2  Multi6/shim6 . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3  Resolver issues  . . . . . . . . . . . . . . . . . . . . .   5
     3.4  Local management of host identity namespace  (including
          security/privacy issues) . . . . . . . . . . . . . . . . .   6
     3.5  Interactions with host firewalls . . . . . . . . . . . . .   6
     3.6  IPsec implementation issues  . . . . . . . . . . . . . . .   6
     3.7  IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . .   7
     3.8  What have early adoptors learned from experience?  . . . .   7
   4.   Application Implications . . . . . . . . . . . . . . . . . .   8
     4.1  Static vs. dynamic linking of resolver library . . . . . .   8
     4.2  Using legacy API . . . . . . . . . . . . . . . . . . . . .   8
     4.3  Using native API . . . . . . . . . . . . . . . . . . . . .   8
   5.   Infrastructure Implications  . . . . . . . . . . . . . . . .   9
     5.1  Issues with global management of the host identity
          namespace  . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2  Legacy NAT traversal . . . . . . . . . . . . . . . . . . .   9
     5.3  Impact on DNS  . . . . . . . . . . . . . . . . . . . . . .   9
     5.4  Firewall issues  . . . . . . . . . . . . . . . . . . . . .   9
     5.5  Access control lists based on HITs . . . . . . . . . . . .   9
     5.6  HIP aware middleboxes  . . . . . . . . . . . . . . . . . .   9
     5.7  HIT resolution infrastructure  . . . . . . . . . . . . . .  10
     5.8  Rendezvous servers . . . . . . . . . . . . . . . . . . . .  10
     5.9  Debugging  . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.10   Tying into existing PKIs . . . . . . . . . . . . . . . .  11
   6.   General Implications . . . . . . . . . . . . . . . . . . . .  12
   7.   HIP Research Activities  . . . . . . . . . . . . . . . . . .  13
   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  14
   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  14
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  15
        Intellectual Property and Copyright Statements . . . . . . .  16













Henderson & Gurtov      Expires January 21, 2006                [Page 2]


Internet-Draft            HIP Experiment Report                July 2005


1.  Introduction

   This document summarizes the work and experiences of the Host
   Identity Protocol IRTF Research Group (HIP-RG).  The HIP-RG was
   chartered to explore the possible benefits and consequences of
   deploying the Host Identity Protocol architecture [2] in the
   Internet.

1.1  What is HIP?

   The Host Identity Protocol introduces a new name space, the "host
   identity" name space, to the Internet architecture.  The express
   purpose of this new name space is to allow for the decoupling of
   identifiers (host identities) and locators (IP addresses) in the
   architecture.  The authors and technical contributors to HIP have
   assumed that HIP will allow for alternative solutions for several of
   the Internet's challenging technical problems.  Although there have
   been many architectural proposals to decouple identifiers and
   locators over the past 20 years, HIP is currently the most actively
   developed proposal in this area.  A number of experimental draft
   specifications are in work in the IETF's HIP Working Group, including
   the  HIP base protocol [3], among other drafts dealing with mobility
   management, DNS resource records, and HIP rendezvous servers.

1.2  Scope

   The research group is tasked with producing an "experiment report"
   documenting the collective experiences and lessons learned from other
   studies, related experimentation, and designs completed by the
   research group.  The question of whether the basic identifier/locator
   split assumption is valid falls beyond the scope of this research
   group.  When indicated by its studies, the HIP RG can suggest
   extensions and modifications to the protocol and architecture.  It is
   also in scope for the RG to study, in a wider sense, the consequences
   and effects that wide-scale adoption of any type of separation of the
   identifier and locator roles of IP addresses is likely to have.















Henderson & Gurtov      Expires January 21, 2006                [Page 3]


Internet-Draft            HIP Experiment Report                July 2005


2.  The ID/Locator Split

   The topic of whether a new name space is needed for the Internet is
   controversial.  The Name Space Research Group (NSRG) at the IRTF was
   not able to reach consensus on the issue, nor even to publish a final
   report.  The IRTF HIP research group is tasked to evaluate the impact
   of deployment of a HIP or related name space in the Internet.  Yet,
   there seems to be little disagreement that, for many scenarios, some
   level of indirection from network name to network location is
   essential or highly desirable to provide adequate service.  Mobile IP
   [1] is one example (the first such Standards Track proposal), with
   particular deployment and security properties, that reuses an
   existing name space for host naming.  Since Mobile IP was finalized
   many new variants to providing this indirection have been suggested.

   Most recently, there has been standardization and development efforts
   in the IETF and IRTF on multi6 protocols and HIP.  In the research
   community, several related proposals have been explored, such as the
   Internet Indirection Infrastructure (i3) [4], IPNL [5], DataRouter
   [6], Network Pointers [7], FARA [8], and TRIAD [9].

   HIP provides a rapid exchange of Host Identities (public keys)
   between hosts and uses a Sigma-compliant Diffie-Hellman key exchange
   to establish shared secrets between such endpoints [3].  The protocol
   is designed to be resistant to Denial-of-Service (DoS) and Man-in-
   the-middle (MitM) attacks, and when used together with another
   suitable security protocol, such as Encapsulated Security Payload
   (ESP) [10], it provides encryption and/or authentication protection
   for upper layer protocols such as TCP and UDP, while enabling
   continuity of communications across network layer address changes.





















Henderson & Gurtov      Expires January 21, 2006                [Page 4]


Internet-Draft            HIP Experiment Report                July 2005


3.  End-host Stack Implications

   There are two primary ways to support HIP in an end-host.  The first
   is to make changes to the kernel implementation to directly support
   the decoupling of identifier and locator.  Although this type of
   modification is the higher performing approach, it is also the more
   challenging to deploy.  The second approach is to implement all HIP
   processing in user-space, and configure the kernel to pass packets
   through user-space for HIP processing.

   The following public HIP implementations are known:

   o  HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications
      and user-space keying daemon;

   o  HIPL (http://infrahip.hiit.fi)-- Linux kernel implementation;

   o  OpenHIP (http://www.openhip.org)-- Linux kernel modifications and
      user-space keying daemon, plus a fully user-space Windows XP
      implementation;

   o  pyHIP (http://www.sharemation.com/adm01bass/)-- Fully user-space
      implementation written in python (no longer maintained).


3.1  Transport issues (CELP, MAST)

   TODO

3.2  Multi6/shim6

   TODO

3.3  Resolver issues

   Much initial experimentation with HIP has involved using HITs
   directly in IPv6 socket calls.  To do so requires some type of a
   priori HIT exchange, in the absence of a resolution service.  Manual
   exchange of HITs has been a major inconvenience  for experimentation.
   It can be overcome via 1) opportunistic HIP mode, 2) storing HITs in
   DNS AAAA entries, 3) name resolution service such as OpenDHT, or 4) a
   HIT exchange service.

   At the time of writing, #1 is only supported by OpenHIP, and #2 is
   only supported by HIP4BSD.  Implementing the first approach in a
   clean way is challenging, as HITs need to be known when an
   application binds to a socket.  Approach #2 has been difficult in
   practice due to resistance of sysadmins for including AAAA entries in



Henderson & Gurtov      Expires January 21, 2006                [Page 5]


Internet-Draft            HIP Experiment Report                July 2005


   the DNS server.  However, using a widely available third-party DNS
   service has a low cost.  Approach #3 is being progressed with two
   independent implementations of HIP-OpenDHT interface.  At the moment,
   the easiest way for enabling experimentation appears to be the
   approach #4 when a shell script based on SSH and SCP can connect to a
   peer machine and copy HITs to the local configuration files.
   However, this approach is not scalable or secure for the long run.

3.4  Local management of host identity namespace  (including security/
     privacy issues)

   One issue not being addressed by most experimental implementations is
   how to manage possibly multiple host identities (some may be
   unpublished).  This is akin to source address selection for transport
   sockets.  How much HIP policy to expose to users is a user interface
   issue.  Default or automatic configuration guesses might have
   undesirable privacy implications for the user.

   HIIT has implemented an extension of native API to control multiple
   host identities (refer to Karlsson's Master's thesis).

3.5  Interactions with host firewalls

   HIP is presently an experimental protocol, and some default firewall
   configuration scripts on popular Linux distributions do not permit
   such traffic.  Determining which rules to modify without compromising
   other performance can be tricky; the default rule set on one popular
   distribution has over 100 rules.  Moreover, it may be the case that
   the end user has no control over the firewall settings, if
   administered by an enterprise IT department.

3.6  IPsec implementation issues

   HIP requires a Bound End-to-End Tunnel (BEET) mode of ESP operation,
   which mixes tunnel-mode semantics with transport-mode syntax.  BEET
   is not supported by any known operating system distributions at
   present, so kernel modifications must be made to obtain true kernel
   support using existing IPsec code.

   The current strategy that implementors have adopted is to develop a
   common IPsec BEET patch for the Linux kernel.  The patch could
   potentially allow all implementations to run in the userspace and use
   a common clean interface towards the kernel.  Still, the BEET patch
   introduces problems for the opportunistic HIP mode when HITs are used
   at the socket API.

   Another inconvenience experienced in current Linux implementations
   (due to the native IPsec implementation, not HIP specifically) is a



Henderson & Gurtov      Expires January 21, 2006                [Page 6]


Internet-Draft            HIP Experiment Report                July 2005


   loss of the first data packet that triggers the HIP association
   establishment.  Instead, this packet should be cached and transmitted
   after the association is established.

3.7  IPv4 vs. IPv6 issues

   TODO

3.8  What have early adoptors learned from experience?

   Installing several HIP implementations onto a single machine was
   creating some complications.  All implementations store some files in
   /etc/hip directory and use /proc system to report the status.  While
   direct conflicts in filenames were luckily avoided, it might have
   been better to coordinate from the beginning so that different
   implementations, for example, use different subdirectories.

   The experience with attempting to integrate the HIPL kernel-based
   implementation to the official Linux kernel has been negative.
   Although counter examples exist, e.g.  SCTP is a large unit in the
   kernel, the Linux community resisted incorporating the HIP code.  It
   was motivated by a possibility to run HIP in the user space.
   Experimental results comparing kernel vs. userspace HIP
   implementations in terms of performance and DoS resilience are
   needed.  If the kernel implementation is shown to perform
   significantly better than the userspace implementation, it may be a
   sufficient justification to incorporate HIP to kernel.

   Opportunities for misconfiguration of the Linux kernel have been a
   side effect of the need to patch the kernel.  Mistakenly disabling a
   configuration option or compiling a feature as a module instead of
   statically caused many installation problems.  Some scripts that
   could verify that the configuration is appropriate could help to
   solve this problem, as could fully user-space test implementations.

















Henderson & Gurtov      Expires January 21, 2006                [Page 7]


Internet-Draft            HIP Experiment Report                July 2005


4.  Application Implications

4.1  Static vs. dynamic linking of resolver library

   Using HIPL, several legacy applications were shown to work without
   changes using dynamic re-linking of the resolver library.  This way,
   Firefox web browser successfully worked with an Apache web server.
   The re-linking just requires configuring a LD_PRELOAD system variable
   that can be easily done in a user shell profile file or as a start-up
   wrapper for an application.

4.2  Using legacy API

   OpenHIP legacy API allows using most HIP-unaware applications in a
   transparent way (Refer to Henderson et al. draft).

4.3  Using native API

   Several applications, including telnet and FTP, have been ported to
   use the native HIP API in HIPL.  A concern that FTP would not work
   due to the problem of application referral, i.e. passing an the IP
   address within application messages, was solved.  FTP is shown to
   work well in the passive and active modes.  (Refer to Komu et al.
   Mobicom workshop paper).



























Henderson & Gurtov      Expires January 21, 2006                [Page 8]


Internet-Draft            HIP Experiment Report                July 2005


5.  Infrastructure Implications

5.1  Issues with global management of the host identity namespace

   TODO

5.2  Legacy NAT traversal

   Legacy NAT traversal is being implemented for HIPL according to the
   PATH draft.  While IPv6 mode is ready, IPv4 is still in progress
   (IPv4 is still unstable in HIPL).  Finding an IPv6 NAT implementation
   for experiments has been difficult.  Tests and performance
   measurements with an IPv4 NAT (WLAN access point) will be executed.

   A next topic is experimenting with legacy NAT traversal when both
   peers reside beyond a NATs.  One possibility is to run STUN servers
   on PlanetLab to enable NAT traversal.

5.3  Impact on DNS

   Initially, HITs were expected to be stored as AAAA entries in DNS.
   This is a source of potential confusion for HIP unaware applications
   that cannot distinguish between a HIT and a valid IPv6 address.

   What is the impact of HIP resource records on DNS?  DNS extensions
   are currently under development by NEC Eurolabs.

5.4  Firewall issues

   HIIT has implemented a HIP firewall based on Linux iptables.  (Refer
   to Vehmersalo's Master's thesis.)

5.5  Access control lists based on HITs

   TODO

5.6  HIP aware middleboxes

   A design of a HIP registration protocol for architectured NATs has
   been completed and published.  Performance measurement results with a
   prototype are available, but experimentation on a wide scale is still
   missing.  (Refer to Tschofenig et al).

   As argued by Aura et al., the encryption of the Responder HI prevents
   NAT and firewall support for HIP.  The catch is that when the HI is
   encrypted, middle boxes in the network cannot verify the signature on
   I2 and, thus, cannot safely create a state for the HIP association.
   On the other hand, if the HI is not encrypted, a stateful middle box



Henderson & Gurtov      Expires January 21, 2006                [Page 9]


Internet-Draft            HIP Experiment Report                July 2005


   like a NAT can process I2 and create a protocol state for the
   possible to push the I1/R1 exchange into the firewall and to filter
   false puzzle solutions at the firewall.  The encryption of HI-I
   prevents such middle-box implementations.  (Refer to Aura et al.)

5.7  HIT resolution infrastructure

   OpenDHT resolution has been implemented by Aalborg University,
   Denmark and by Boeing.  (Add references).

   The prototype of the Host Identity Indirection Infrastructure (Hi3)
   has been implemented using OpenHIP and i3 software.  A set of 25 i3
   servers is running on PlanetLab.  While a PlanetLab account is
   required to run the servers, anybody can openly use the provided
   service.

   The main idea is to transmit HIP control packets using the i3 system
   as a lookup and rendezvous service, while transmitting data packets
   efficiently end-to-end using IPsec.  Performance measurements are
   being executed, comparing the association setup latency, throughout
   and RTT of Hi3 with plain IP, HIP and i3.

   One difficulty has been with debugging the i3 system.  In some cases
   the messages did not traverse i3 correctly; due to its distributed
   nature and lack of tracing tools, making the system work has been
   challenging.  Fortunately, these shortcomings are being addressed.

   NATs and firewalls were a major disturbing factor in execution of
   experiments.  Many networks did not allow incoming UDP packets to go
   through, therefore, preventing messages from i3 servers to reach the
   client.

   So far the Hi3 system has been evaluated on a larger scale only
   analytically.  The problem is that running a larger number of clients
   to create a sufficient load for the server is difficult.  A cluster
   on the order of a hundred Linux servers is needed for this purpose.
   Contacts to a State Supercomputer Centre in Finland have not been
   successful so far.  A possible opportunity is to use one of existing
   Emulab installations, e.g. in Utah for these tests.

5.8  Rendezvous servers

   A rendezvous server (RVS) has been implemented by HIIT for HIPL.
   Initial experimentation produced following observations.

   o  RVS is essential for fast initial contact; DynDNS is not as fast
      yet.




Henderson & Gurtov      Expires January 21, 2006               [Page 10]


Internet-Draft            HIP Experiment Report                July 2005


   o  RVS improves fault tolerance for multihoming.

   o  Registration of a HIP host to RVS loads the host significantly.

   Following advanced concepts need further study.

   o  Multiple RVS per host for fault tolerance (e.g. one rendezvous
      node crashes).  An algorithm for selecting the best RVS.

   o  Load balancing.  A RVS server could distribute I1s to different
      responders if the responder's identity is shared or opportunistic
      HIP is used.

   o  Offering a rendezvous service in a P2P fashion by HIP hosts.


5.9  Debugging

   TODO

5.10  Tying into existing PKIs

   TODO




























Henderson & Gurtov      Expires January 21, 2006               [Page 11]


Internet-Draft            HIP Experiment Report                July 2005


6.  General Implications

   TODO
















































Henderson & Gurtov      Expires January 21, 2006               [Page 12]


Internet-Draft            HIP Experiment Report                July 2005


7.  HIP Research Activities

   The following is a possibly incomplete list of current research
   activities related to HIP.

   Boeing (T. Henderson, J. Ahrenholz.  OpenHIP implementation, OpenDHT)

   Nomadiclab, Ericsson (P. Jokela, P. Nikander, J. Melen.  BSD HIP
   implementation)

   HIIT (A. Gurtov, M. Komu, A. Pathak, D. Beltrami.  HIPL, legacy NAT
   traversal, firewall, i3, native API)

   UCB (D. Joseph, HIP proxy implementation)

   Laboratory of Computer Architecture and Networks, Polytechnic School
   of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements,
   Hi3)

   Telecom Italia (M. Morelli, comparing existing HIP implementations)

   NEC Heidelberg (L. Eggert, M. Esteban working on RVS implementation,
   DNS)

   U. of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration
   protocol)

   U. of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-
   OpenDHT)

   University of Parma (UNIPR), Department of Information Engineering
   Parma, Italy.  N. Fedotova (HIP for P2P)

   Siemens (H. Tschofenig, HIP middleboxes)

   Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft,
   HIP evaluation project, OpenDHT-HIP interface)

   Microsoft Research, Cambridge (T. Aura, HIP analysis)

   MIT (H. Balakrishnan.  Delegation-Oriented Architecture)










Henderson & Gurtov      Expires January 21, 2006               [Page 13]


Internet-Draft            HIP Experiment Report                July 2005


8.  Acknowledgments

   Miika Komu.

9.  References

   [1]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [2]   Moskowitz, R., "Host Identity Protocol Architecture",
         draft-ietf-hip-arch-02 (work in progress), January 2005.

   [3]   Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01
         (work in progress), October 2004.

   [4]   Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana,
         "Internet Indirection Infrastructure (i3)",  Proceedings of ACM
         SIGCOMM, August 2002.

   [5]   Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker,
         S., Stoica, I., and M. Walfish, "A Layered Naming Architecture
         for the Internet",  Proceedings of ACM SIGCOMM, August 2004.

   [6]   Touch, J. and V. Pingali, "DataRouter:  A Network-Layer Service
         for Application-Layer Forwarding",  Proceedings of
         International Workshop on Active Networks (IWAN),
         December 2003.

   [7]   Tschudin, C. and R. Gold, "Network Pointers",  ACM Computer
         Communications Review, January 2003.

   [8]   Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA:
         Reorganizing the Addressing Architecture",  Proceedings of ACM
         SIGCOMM FDNA Workshop, August 2003.

   [9]   Cheriton, D. and M. Gritter, "TRIAD:  A New Next-Generation
         Internet Architecture",  Unpublished, available at Citeseer,
         July 2000.

   [10]  Kent, S., "IP Encapsulating Security Payload (ESP)",
         draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.










Henderson & Gurtov      Expires January 21, 2006               [Page 14]


Internet-Draft            HIP Experiment Report                July 2005


Authors' Addresses

   Tom Henderson
   The Boeing Company
   P.O. Box 3707
   Seattle, WA
   USA

   Email: thomas.r.henderson@boeing.com


   Andrei Gurtov
   HIIT
   Helsinki Institute for Information Technology
   Advanced Research Unit (ARU)
   P.O. Box 9800
   Helsinki  FIN-02015-HUT
   FINLAND

   Phone: +358 9 451 1
   Email: gurtov@cs.helsinki.fi






























Henderson & Gurtov      Expires January 21, 2006               [Page 15]


Internet-Draft            HIP Experiment Report                July 2005


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




Henderson & Gurtov      Expires January 21, 2006               [Page 16]