Network Working Group                                          P. Jokela
Internet-Draft                                                  J. Melen
Expires: December 20, 2006                                    J. Ylitalo
                                            Ericsson Research NomadicLab
                                                           June 18, 2006


                         HIP Service Discovery
                 draft-jokela-hip-service-discovery-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 December 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo specifies a service discovery mechanism to be used with the
   Host Identity Protocol (HIP).








Jokela, et al.          Expires December 20, 2006               [Page 1]


Internet-Draft            HIP Service Discovery                June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terms and Definitions  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements Terminology . . . . . . . . . . . . . . . . .  4
     2.2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Service Discovery Mechanism  . . . . . . . . . . . . . . .  5
     3.1.  Different Discovery methods  . . . . . . . . . . . . . . .  5
     3.2.  On-the-Path Service Discovery  . . . . . . . . . . . . . .  5
       3.2.1.  Passive discovery  . . . . . . . . . . . . . . . . . .  6
     3.3.  Regional Service Discovery . . . . . . . . . . . . . . . .  7
   4.  Parameter and Packet Formats . . . . . . . . . . . . . . . . .  9
     4.1.  Service Discovery Packet . . . . . . . . . . . . . . . . .  9
     4.2.  Service Announcement Packet  . . . . . . . . . . . . . . .  9
   5.  Packet Processing  . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Initiating an HIP Service Discovery  . . . . . . . . . . . 11
       5.1.1.  Using Regional Service Discovery . . . . . . . . . . . 11
       5.1.2.  Using On-Path Service Discovery  . . . . . . . . . . . 11
     5.2.  Processing an Incoming SD Packet . . . . . . . . . . . . . 12
     5.3.  Processing an Incoming SA  . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18


























Jokela, et al.          Expires December 20, 2006               [Page 2]


Internet-Draft            HIP Service Discovery                June 2006


1.  Introduction

   In the Host Identity Protocol Architecture [5], hosts are identified
   with public keys.  The Host Identity Protocol [6] base exchange
   allows any two HIP-supporting hosts to authenticate each other and to
   create a HIP association between themselves.  During the base
   exchange, the hosts generate a piece of shared keying material using
   an authenticated Diffie-Hellman exchange.  The Host Identity Protocol
   (HIP) Registration Extension [4] document specifies how a HIP host
   can register to use a service provided by another HIP node, typically
   a middle-box, or a server.  However, the registration specification
   does not specify how a HIP host can locate such nodes providing
   services.

   This document specifies a method that can be used by HIP hosts to
   find nodes in the local network that are providing services for HIP
   hosts.  A HIP host can discover the available services in two ways.
   In the first case, the service provider on the end-to-end
   communication path listens to traffic.  Once the HIP host sends
   either I1, UPDATE or Service Discover Packet (SDP) message to the
   peer node, the service provider replies back to the HIP host with a
   Service Announcement Packet.  In the second case, the HIP host may
   initiate the service discovery by sending a Service Discovery packet
   to the network, either using a link-local or site-local address.
   This makes it also possible to find service providers which are not
   located on the packet forwarding path.

   This document describes only the service discovery.  How the host
   registers to services is defined in the "HIP Registration Extension"
   [4] specification.





















Jokela, et al.          Expires December 20, 2006               [Page 3]


Internet-Draft            HIP Service Discovery                June 2006


2.  Terms and Definitions

2.1.  Requirements 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 RFC2119 [1].

2.2.  Definitions

   IP_TTL:  The TTL in IPv4 or hop limit in IPv6 field in the IP header.

   SDP_MAX_TTL:  The maximum TTL that is used in on-path discovery
      mechanism.  The value is implementation specific.

   SD_MAX_WAIT:  The maximum time the host waits in the SD_SENT state
      after sending a Service Discovery message to the network.


































Jokela, et al.          Expires December 20, 2006               [Page 4]


Internet-Draft            HIP Service Discovery                June 2006


3.  The Service Discovery Mechanism

   The provided services can vary from services that are located at the
   end-host to services that are provided by middle-boxes, e.g.
   Rendezvous type services.  Depending on the service the HIP host is
   willing to locate, it may use different service discovery scopes.

3.1.  Different Discovery methods

   A HIP host can initiate a service discovery with different target
   scopes.  It can detect services that are provided on the forwarding
   path to a certain host located in another network (e.g. towards its
   own Rendezvous Server), or it can detect services in a certain
   network area.

   The figure below illustrates a simplified example of a Service
   Discovery Packet (SDP) and Service Announcement Packet (SAP)
   exchange.  The SD packet may contain the REG_INFO parameter where the
   sending host can define the services that it wants to get information
   about.  In the SA packet message, the REG_INFO is mandatory
   containing the services provided by the sending node.  Additionally,
   the SA packet may contain R1-packet parameters, allowing the
   requesting HIP host to continue the Base Exchange and service
   registration directly with an I2 packet.

         HIP host                     Service Provider

               SDP: [REG_INFO]
             -------------------------->
                                       verify conditions
                                       create response
               SAP: REG_INFO [+ R1 parameters]
             <-------------------------
                                       remain stateless

            possible service registration completion
              I2
             --------------------------->
              R2
              <---------------------------

3.2.  On-the-Path Service Discovery

   A HIP host that is willing to locate service providers on the end-to-
   end packet forwarding path initiates a service discovery process by
   generating an SD packet with an optional REG_INFO parameter.  The
   destination IP address of the SD packet is set to the IP address of
   the peer node towards which the service discovery is done.



Jokela, et al.          Expires December 20, 2006               [Page 5]


Internet-Draft            HIP Service Discovery                June 2006


   The HIP host sets the local IP_TTL value to one, and sets the IP
   packets TTL to this value.  When it gets the ICMP Time Exceeded
   response, it increases the IP_TTL value by one, sets the TTL in the
   IP packet to this new value, and resends the SD packet to the
   network.  This continues, until the value of the IP_TTL exceeds the
   SDP_MAX_TTL value, or the HIP host has received SA packet(s) from
   service providers.

   Each host on the path that is providing services, responds to an
   incoming request with an SA packet containing all the services it
   provides, or if the SD packet contained the REG_INFO parameter, only
   the intersection of provided and requested services.

   In addition to the REG_INFO parameter, the SA packet MAY optionally
   contain all parameters that are provided in an R1 packet.  This
   enables the Initiator to use that packet as an R1 packet and continue
   base exchange and service registration with the service provider by
   sending an I2 packet to it.  If successful, the R2 packet from the
   service provider finalizes the connection setup and service
   registration.

3.2.1.  Passive discovery

   In some cases, the HIP host may not want to actively query services.
   One such a situation is when a mobile host moves behind a mobile
   router.  It is not feasible to do mobile router discovery every time
   the host moves.  In this case it is better to let the service
   providing node to send the service announcement based on passing by
   HIP packets, for example I1 or UPDATE packet.

   The figure below shows a passive service discovery message exchange
   between the HIP host and the service provider.  The outgoing I1
   packet is sent to peer HIP host, and the service providing node MAY
   verify the I1 source HIT and compare it to the nodes it is currently
   serving.  If that particular host is not yet served, the service
   provider MAY send an SA packet to the original I1 sender containing
   information about the services it can provide.

   NOTE: In this case, the Initiator does not have any state related to
   the incoming SA packet and the state machine must allow it to accept
   and process such a packet.










Jokela, et al.          Expires December 20, 2006               [Page 6]


Internet-Draft            HIP Service Discovery                June 2006


       HIP host                       Service Provider     Destination
                                                              Host

               I1: srcHIT, dstHIT
             ----------------------------------/\----------->
                               - check passing I1 packet
                               - verify conditions
                               - verify server's "served nodes"
                                 information
                               - create response, if needed
               SAP: REG_INFO [+ R1 parameters]
             <-------------------------
                                 remain stateless

            possible service registration completion
                 I2
             --------------------------->
                 R2
             <---------------------------

3.3.  Regional Service Discovery

   When the HIP host is trying to discover services in a certain network
   region, it sends one or more SD packets to the network multicast
   addresses.  It creates an SD packet, with an optional REG_INFO
   parameter, sets the destination HIT to NULL (all zeros), and selects
   the destination multicast / broadcast address depending on the region
   from where services are discovered.

   The service providing nodes respond to such a requests with an SA
   packet, where the source HIT is the server's HIT, destination HIT the
   requesting HIP node's HIT, and source IP address the server's IP
   address.  The REG_INFO parameter contains services provided by the
   server, and if the SD packet contained the REG_INFO parameter, only
   the intersection of services provided and requested.  The SA packet
   can optionally contain R1 parameters that the requesting node can use
   for faster Base Exchange and service registration.

   In IPv6, the host can use the following destination addresses
   (RFC4291 [2]):

     All nodes multicast address    FF02:0:0:0:0:0:0:1 (link-local)
     All routers multicast address  FF02:0:0:0:0:0:0:2 (link-local)
     All routers multicast address  FF05:0:0:0:0:0:0:2 (site-local)

   Typically, when a host is looking for a server providing rendezvous
   service, it must be aware that the server is not necessarily on the
   same link.  In that case it can use the "All routers multicast" site-



Jokela, et al.          Expires December 20, 2006               [Page 7]


Internet-Draft            HIP Service Discovery                June 2006


   local address as the destination address of the SD packet.

   In IPv4, the service discovery is limited to local link, where the
   following destination address is used (RFC0919 [3]):

     All nodes on the link          255.255.255.255













































Jokela, et al.          Expires December 20, 2006               [Page 8]


Internet-Draft            HIP Service Discovery                June 2006


4.  Parameter and Packet Formats

   The Service Discovery defines one new HIP packet to be used for
   searching services provided by hosts at the local link, or at the
   local site.  The service information is transferred in the REG_INFO
   parameter, defined in [4].

4.1.  Service Discovery Packet

   The Service Discovery packet resembles the I1 packet.  In basic form,
   when the HIP host does not want to send any specific information
   about the services it is looking for, the SD packet contains only the
   HIP header information.  However, in some cases the HIP host may want
   to send information about the service it is searching for by adding a
   REG_INFO parameter in the packet, listing the services of which it is
   willing to receive offers.

   The HIP header values for the SD packet:

      Header:
        Packet Type = TBD
        SRC HIT = Initiator's HIT
        DST HIT = NULL

      IP ( HIP ( [ REG_INFO ] ) )


   Valid control bits: none

4.2.  Service Announcement Packet

   The Service Announcement packet is sent by a server as a response to
   the SD packet (active service detection) or as a response to a
   passing-by I1 or UPDATE packet (passive service detection).

   The HIP header values and packet format for the SA packet (with
   connection initialization parameters):














Jokela, et al.          Expires December 20, 2006               [Page 9]


Internet-Draft            HIP Service Discovery                June 2006


      Header:
        Packet Type = TBD
        SRC HIT = Service Provider's HIT
        DST HIT = Initiator's HIT

      IP ( HIP ( [ R1_COUNTER, ]
                 PUZZLE,
                 DIFFIE_HELLMAN,
                 HIP_TRANSFORM,
                 HOST_ID,
                 [ ECHO_REQUEST, ]
                 REG_INFO,
                 HIP_SIGNATURE_2
                 [, ECHO_REQUEST ] ) )

   The HIP header values and packet format for the SA packet (without
   connection initialization parameters):

      Header:
        Packet Type = TBD
        SRC HIT = Service Provider's HIT
        DST HIT = Initiator's HIT

      IP ( HIP ( REG_INFO ) )


   Valid control bits: none

   If the sending host included the connection initialization parameters
   in the SA packet, then the sending host MUST considers the sent SA
   packet as a sent R1 packet.  All parameters (except the REG_INFO
   parameter) are described in the "Host Identity Protocol" [6]
   document.

   The REG_INFO parameter is defined in the "HIP Registration Extension"
   [4] document.















Jokela, et al.          Expires December 20, 2006              [Page 10]


Internet-Draft            HIP Service Discovery                June 2006


5.  Packet Processing

5.1.  Initiating an HIP Service Discovery

   When a HIP host is willing to receive service information from the
   network, it creates an SD packet to be sent to the local network.

   The SD packet header consists of the HIP header, where the
   destination HIT field is set to NULL (all zeros).  The source HIT is
   the sending node's HIT.

   The destination IP address can be selected from the set defined in
   Section 3.  To which address the packet is sent, depends on the IP
   version used in the network and type of the service that the host is
   requesting: The host may use heuristics to decide if a certain
   service is provided by a host or by a router and send the packet
   using an appropriate destination address.

   The sending host moves to an SD_SENT state, which resembles the state
   of I1_SENT ([6]).  The difference is that in SD_SENT state, the host
   must handle and store the required service information provided by
   the server, and it must make the decision to continue the Base
   Exchange by sending I2, or just wait for additional SAPs, until the
   SD_MAX_WAIT timer expires.

5.1.1.  Using Regional Service Discovery

   1.  A host creates an SD packet, sets the destination HIT to NULL
       (all zeros), and its local HIT as the source HIT.  It MAY insert
       a list of services that it is interested in into an optional
       REG_INFO parameter.

   2.  The host decides the area that is needed to be probed for
       services.  The host can select between link-local services (IPv4
       and IPv6), on-path services (IPv4 and IPv6), or site-local
       services (IPv6 only).

   3.  If the desired area scanned is either link- or site-local, the
       host inserts the respective destination IP-address to the packet
       and sends it to the network.

5.1.2.  Using On-Path Service Discovery

   When the host is willing to probe for services on a packet forwarding
   path (e.g. towards its home rendezvous server), it starts the On-the-
   Path Service Discovery Process.





Jokela, et al.          Expires December 20, 2006              [Page 11]


Internet-Draft            HIP Service Discovery                June 2006


   1.  A host creates an SD packet, sets the destination HIT to NULL
       (all zeros), and its local HIT as the source HIT.  It MAY insert
       a list of services that it is interested in into an optional
       REG_INFO parameter.

   2.  The host initializes the IP_TTL counter to one, and sets the
       value in to the IP header.  The packet's destination IP address
       must be such that it is routed outside the network.  The host
       sends the packet towards the destination host.

   3.  If an SA packet is received from the network, the host may have
       found an service provider on the path.  The packet is processed
       according to Section 5.3.  The Service Discovery process may
       continue simultaneously, unless the host decides otherwise.

   4.  When the host receives an ICMP Time Exceeded message from the
       network, it increases the IP_TTL counter, verifies that the
       counter hasn't exceeded the SDP_MAX_TTL limit, and resends the
       packet to the same address.

5.2.  Processing an Incoming SD Packet

   A host receiving an SD packet, MUST drop the packet if the IP_TTL has
   exceeded and reply with ICMP Time Exceeded.

   1.  The receiver of the SD packet MUST verify that the source IP
       address is a unicast address.  If it is not, the packet is
       silently dropped.

   2.  The receiver of the SD packet MUST verify that the destination
       HIT is NULL.  If this is not the case, the packet is forwarded if
       IP_TTL has not been exceeded.  If the IP_TTL was exceeded, the
       receiver either send's ICMP Time Exceeded as a reply to a SD
       packet if the IP header contained a unicast source address or
       silently drop's the SD packet if the source address was not
       unicast address.  NOTE: if the HIP host is trying to find out
       services provided by a known host, it can send an SD packet to
       the host with the correct destination HIT as defined in [4].

   3.  The receiver MAY verify if local policy allows it to respond to
       such a service discovery request.  If it does not, the packet is
       forwarded if IP_TTL has not been exceeded.  If the IP_TTL was
       exceeded, the receiver either send's ICMP Time Exceeded as a
       reply to a SD packet if the IP header contained a unicast source
       address or silently drop's the SD packet if the source address
       was not unicast address.





Jokela, et al.          Expires December 20, 2006              [Page 12]


Internet-Draft            HIP Service Discovery                June 2006


   4.  If the request in the SD packet doesn't contain the REG_INFO
       parameter, the receiver creates an SA packet containing all the
       services that can be provided for the requesting host in the
       enclosed REG_INFO parameter.  The destination IP address of that
       SA packet is the sender of the original SD packet, source IP
       address is the one of IP addresses on that interface from where
       the SD packet arrived, Initiator HIT is the HIT of the SD packet
       sender, and the Responder HIT is the hit of itself.

   5.  The service provider waits a random time (between zero and TBD
       maximum time) before sending the SA packet to the requesting
       host.  This prevents all SAs from different service providers
       arriving at the same time to the requesting host.

   6.  The service provider MUST rate limit the outgoing SA packets, to
       avoid reflection attacks.

   7.  Note: It is possible that the source IP address in the SD packet
       is spoofed.  In this case, the Service Announcement packet is
       sent to a host that has not requested it.

5.3.  Processing an Incoming SA

   When a host has sent either an SD, I1 or UPDATE packet, it may
   receive an SA packet announcing services.

   1.  The incoming SA packet is verified: The destination HIT in the SA
       packet must match the local HIT and the destination IP address
       MUST be a unicast address.  Otherwise the packet is silently
       dropped.

   2.  The host may be in

       1.  SD_SENT state, if it has initiated an active service
           discovery process.

       2.  UNESTABLISHED state, if the SA packet is a result of passive
           service detection or the SA has been sent unsolicited.

   3.  If the host is in SD_SENT state, it verifies the incoming SA
       packet, and stores the required information from the incoming
       packet.

   4.  If the host is not in SD_SENT state, the SA packet is a result of
       passive service detection, or the service provider has sent it
       unsolicited.  In that case the host MAY store the required
       information from the incoming packet depending on its own policy.
       NOTE: A service provider can announce services without any



Jokela, et al.          Expires December 20, 2006              [Page 13]


Internet-Draft            HIP Service Discovery                June 2006


       trigger.  This MAY open the HIP host that receives the SA packet
       to an attack where the attacker can establishes security
       association with the HIP host.  To protect from this kind of
       attack, the HIP host different alternatives.  In the first case,
       the host may have access control list (ACL) for HITs of the
       trusted service providers.  In the second case, the host may
       accept incoming unsolicited SA packets during TBD milliseconds
       after each outgoing I1 or UPDATE packet.  Or the host MAY decline
       to send I2 message as a reply to an unsolicited SA packet.

   5.  If the incoming SA packet contains all R1 parameters, the host
       may choose to continue base exchange and service registration
       with the service provider.  If the host did not receive all R1
       parameters the host MUST start the registration by sending I1 to
       service provider.  The host MAY continue all other tasks
       meanwhile registering to the service discovered from the received
       SA packet.

   6.  If the host chooses to register to use a service from that
       service provider, it creates and sends an I2 packet with a
       service registration parameter (REG_REQUEST) as described in [4],
       forks the processing and goes to the I2_SENT state to wait for
       the R2 packet from the server.




























Jokela, et al.          Expires December 20, 2006              [Page 14]


Internet-Draft            HIP Service Discovery                June 2006


6.  Security Considerations

   When a HIP host receives a REG_INFO parameter from the network,
   either as a result of an active service discovery, or passively, it
   cannot know if the service provider is trustworthy.

   The SD packet is unprotected, which makes it vulnerable.  An attacker
   can modify the packet, or an attacker can send the packet using
   someone else's IP address and HIT.










































Jokela, et al.          Expires December 20, 2006              [Page 15]


Internet-Draft            HIP Service Discovery                June 2006


7.  IANA Considerations

   This document defines additional packets for the Host Identity
   Protocol [6].

   o  SD packet is TBD.

   o  SA packet is TBD.


8.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 4291, February 2006.

   [3]  Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919,
        October 1984.

   [4]  Laganier, J., "Host Identity Protocol (HIP) Registration
        Extension", draft-ietf-hip-registration-02 (work in progress),
        June 2006.

   [5]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
        Architecture", draft-ietf-hip-arch-03 (work in progress),
        August 2005.

   [6]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
        (work in progress), March 2006.




















Jokela, et al.          Expires December 20, 2006              [Page 16]


Internet-Draft            HIP Service Discovery                June 2006


Authors' Addresses

   Petri Jokela
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   Email: petri.jokela@nomadiclab.com


   Jan Melen
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   Email: jan.melen@nomadiclab.com


   Jukka Ylitalo
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   Email: jukka.ylitalo@nomadiclab.com
























Jokela, et al.          Expires December 20, 2006              [Page 17]


Internet-Draft            HIP Service Discovery                June 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.




Jokela, et al.          Expires December 20, 2006              [Page 18]