HIP Working Group                                            J. Laganier
Internet-Draft                                    LIP / Sun Microsystems                                          DoCoMo Euro-Labs
Expires: August 19, December 12, 2005                                     L. Eggert
                                                                     NEC
                                                       February 18,
                                                           June 10, 2005

           Host Identity Protocol (HIP) Rendezvous Extension
                         draft-ietf-hip-rvs-01
                         draft-ietf-hip-rvs-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.

   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 become becomes
   aware will be disclosed, in accordance with
   RFC 3668. 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.

   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 19, December 12, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document discusses a Rendezvous rendezvous extension for the Host Identity
   Protocol (HIP).  The Rendezvous rendezvous extension extend extends HIP and the HIP
   registration extension for initiating communication between HIP nodes
   via HIP rendezvous servers.  Rendezvous Servers.  Rendezvous Servers servers improve reachability
   and operation when HIP nodes are multi-homed or mobile.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Overview of Rendezvous Server Operation  . . . . . . . . . . .  4
     3.1   Diagram Notation . . . . . . . . . . . . . . . . . . . . .  6
     3.2   Rendezvous Client Registering with a Rendezvous Server . .  6
     3.3   Establishing HIP Associations via Rendezvous Servers . Registration . .  7
       3.3.1   Encapsulating I1 into a Tunnel . . . . . . . . . . . .  7
       3.3.2   Rewriting I1 IP Header  6
     3.3   Relaying the Base Exchange . . . . . . . . . . . . . . . .  7
       3.3.3   Bidirectional Forwarding of HIP packets  . . . . . . .  8
       3.3.4   Implication on the HIP integrity checks  . . . . . . .  9
   4.  RVS  Rendezvous Server Extensions Definition . . . . . . . . . . . . . . . . . . 10  8
     4.1   Usage and Processing of Existing Parameters  . . . . . . . 11
       4.1.1   ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 11
       4.1.2   REA   LOCATOR Parameter  . . . . . . . . . . . . . . . . . . . . 11  8
     4.2   New   RENDEZVOUS Registration Type . . . . . . . . . . . . . . . . . . 11  8
     4.3   New Parameter Formats and Processing . . . . . . . . . . . 11  9
       4.3.1   RVR_TYPE   RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 12  9
       4.3.2   RVR_HMAC   FROM Parameter . . . . . . . . . . . . . . . . . . 13
       4.3.3   FROM Parameter . . . . . . . . . . . . .  9
       4.3.3   VIA_RVS Parameter  . . . . . . . 14
       4.3.4   TO Parameter . . . . . . . . . . . 10
     4.4   Processing Outgoing I1 Packets . . . . . . . . . . 15
       4.3.5   VIA_RVS Parameter . . . . 10
     4.5   Processing Incoming I1 packets . . . . . . . . . . . . . . 16 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17 12
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13
     8.1   Normative References . . . . . . . . . . . . . . . . . . . . 19 13
     8.2   Informative References . . . . . . . . . . . . . . . . . . 13
       Editorial Comments . . . . . . . . . . . . . . . . . . 19 . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 14
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 20 14
       Intellectual Property and Copyright Statements . . . . . . . . 21 16

1.  Introduction

   The current Internet has a dual use of uses IP addresses. addresses for two purposes.  First, they
   are topological locators for network attachment points.  Second, they
   act as names for the attached network interfaces.  Saltzer [6] [9]
   discusses these naming concepts in detail.  Routing and other
   network-layer mechanisms are based on the locator aspects of IP
   addresses.  Transport-layer protocols and mechanisms typically use IP
   addresses in their role as names for communication endpoints.  This
   dual use of IP addresses limits the flexibility of the Internet
   architecture.  The need to avoid readdressing in order to maintain
   existing transport-layer connections complicates advanced
   functionality, such as mobility, multi-homing, or network
   composition.

   The Host Identity Protocol (HIP) architecture [1] defines a new third
   namespace.  The Host Identity namespace decouples the name and
   locator roles currently filled by IP addresses.  Transport-layer
   mechanisms operate on Host Identities instead of using IP addresses
   as endpoint names.  Network-layer mechanisms continue to use IP
   addresses as pure locators.  Because of this decoupling the HIP layer
   needs to map Host Identities into IP addresses.

   Without HIP, a node needs to know its peer peer's IP address to make an
   initial contact.  The Host Identity Protocol architecture [1] does
   not change this basic property, but introduces an additional additional,
   optional piece of infrastructure, the Rendezvous
   Server (RVS), which rendezvous server (RVS).  An
   RVS serves as an additional initial contact point (rendezvous) ("rendezvous
   point") for nodes trying to reach the RVS its clients.  A  The clients of an RVS offers to a peer it
   serves to relay are HIP nodes that
   use the HIP Registration Protocol [2] to its IP register their HIT->IP
   address mappings with the first packet of a RVS.  After this registration, other HIP
   nodes can initiate a base exchange
   incoming at using the RVS IP address and with of the peer receiver HIT.  A
   peer uses RVS
   instead of the HIP Registration Protocol [2] to register its HIT->IP current IP address mapping with its RVS.  Then of the node they attempt to
   contact.  Essentially, the clients of an initiator and responder can
   have rendezvous together RVS become reachable at the RVS
   RVS' IP address.  The initiator would
   send addresses.  Peers can initiate a I1 packet to HIP base exchange with the RVS
   IP address, address of the RVS, which would then will relay this initial communication
   such that the I1 base exchange may successfully complete.

   When HIP nodes frequently change their network attachment points,
   using a RVS can improve reachability and operation.  Without an RVS,
   a HIP node needs to the responder update its DNS entry with its current IP address.  Then, further communications would
   typically occurs directly without further assistance from address
   before it becomes reachable to its peers.  Although the RVS.

   After DNS offers
   mechanisms for dynamic updates to records[10][11], they may not be
   suitable when a record changes frequently.  Caching, state lifetimes
   and deficiences in existing DNS implementations limit the Base Exchange, rate-of-
   change for a given record.  When using an RVS - which is assumed to
   be reachable at a static or at least infrequently changing IP address
   - HIP nodes use Host Identities instead need not update their DNS records whenever their local IP
   addresses change.  Instead, they register the IP address of their RVS
   in their DNS entry and then update only their RVS when their IP
   addresses change.  Because the RVS is specifically designed to name transport-layer endpoints.  The
   support high-rate updates, this indirection can improve reachability
   of HIP layer in the
   network stack internally translates Host Identities (HI) into
   network-layer IP addresses. nodes.

2.  Terminology

   This section defines terms used throughout the remainder of this
   specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

   In addition to the terminology defined in [2], this document defines
   and uses the following terms:

   Rendezvous Service :
      A HIP Service service provided by a HIP Rendezvous
   Server rendezvous server to its Rendezvous Clients. rendezvous
      clients.  The Rendezvous Server rendezvous server offers to relay some of the incoming HIP packets exchanged during a HIP
      arriving base exchange to the owner of their receiver HIT (i.e. packets between the Rendezvous
   Client or one of its correspondent nodes). initiator and
      responder.  [Comment.1]

   Rendezvous Server (RVS): (RVS)
      A HIP Registrar registrar providing the Rendezvous
   Service. rendezvous service.

   Rendezvous Client (RVC):
      A HIP Requester which requester that has registered for the
   Rendezvous Service rendezvous service at a Rendezvous Server.
      rendezvous server.

   Rendezvous Registration (RVR):
      A HIP Registration registration for the Rendezvous
   Service, rendezvous service, established between a Rendezvous Server
      rendezvous server and a Rendezvous
   Client. rendezvous client.

3.  Overview of Rendezvous Server Operation

   HIP decouples domain names from IP addresses.  Because transport
   protocols bind to Host Identities, host identities, they remain unaware if the set of
   IP addresses associated with a Host Identity host identity changes.  This change
   can have various reasons, including, but not limited to, mobility and
   multi-homing.

                       +-----+                +-----+
                       |     |-------I1------>|     |
                       |  I  |<------R1-------|  R  |
                       |     |-------I2------>|     |
                       |     |<------R2-------|     |
                       +-----+                +-----+

          Figure 1: HIP Base Exchange base exchange without Rendezvous Server rendezvous server.

   Figure 2 shows a simple HIP Base Exchange (without Rendezvous Server) base exchange without a rendezvous
   server, in which the initiator initiates the exchange directly with
   the responder by sending an I1 packet to the responder responder's IP address,
   as per the HIP base specification [4].

   Proposed extensions for mobility and multi-homing [5] allow a HIP
   node to notify its peers about changes in its set of IP addresses.
   These extensions require an established HIP association between two
   nodes, i.e., a completed HIP Base Exchange. base exchange.

   However, such a HIP node might MAY also want to be still reachable by
   potential to other
   future correspondent peers that are unaware of its location change.
   The HIP architecture [1] introduces Rendezvous Servers at which rendezvous servers with whom a
   HIP node MAY register its current HIT host identity tags (HITs) and current IP
   addresses.  The  An RVS basically relays HIP packet incoming at this HIT packets arriving for these HITs to the node
   node's registered IP address.  Thus, addresses.  When a peer publishing its RVS HIP node has registered with
   an RVS, it SHOULD record the IP address instead of its own is reachable
   by means of rendezvous at its RVS IP address. in its DNS record,
   using the HIPRVS DNS record type defined in [12].

                                   +-----+
                          +--I1--->| RVS |---I1--+
                          |        +-----+       |
                          |                      v
                       +-----+                +-----+
                       |     |<------R1-------|     |
                       |  I  |-------I2------>|  R  |
                       |     |<------R2-------|     |
                       +-----+                +-----+

           Figure 2: HIP Base Exchange base exchange with Rendezvous Server a rendezvous server.

   Figure 2 shows a HIP Base Exchange base exchange involving a Rendezvous Server RVS. rendezvous server.  It
   is assumed that HIP node R precedently used previously registered its HITs and current
   IP addresses with the RVS, using the HIP registration protocol [2] to register with the RVS its HIT and IP address. [2].
   When the initiator I tries to establish contact with the responder, responder R,
   it MAY send the I1 of the base exchange either to one of R's DNS
   addresses or it MAY send it
   does not need to know the current IP address of R.  Instead, I is
   aware one of R's rendezvous
   servers instead.  Here, I obtains the RVS IP address of R, at which it R's rendezvous
   server from R's DNS record and then sends an the I1 packet.
   The packet of the HIP
   base exchange to RVS.  RVS, noticing that the receiver HIT contained in the
   arriving I1 packet is not one of its own, but the HIT
   of a HIP node registered for the rendezvous Service, would MUST check its current
   registrations to determine if if needs to relay the
   I1 to packets.  Here,
   it determines that the responder IP address.  Typically HIT belongs to R and then relays the responder would I1 packet
   to the registered IP address.  R then
   complete completes the base exchange
   without further assistance from the RVS by sending an R1 directly to the initiator
   I's IP address. address, as obtained from the I1 packet.

3.1  Diagram Notation

   Notation       Significance
   --------       ------------

   I, R           I and R are the respective source and destination IP
                  addresses of in the IP header

   HIT-I,HIT-R header.

   HIT-I, HIT-R   HIT-I and HIT-R are respectively the Initiator initiator's and the
                Responder HIT of the packet

   REA:I                A REA parameter containing the IP address i is
                present
                  responder's HITs in the HIP header

   FROM:I packet, respectively.

   LOC:I          A FROM LOCATOR parameter containing the IP address I is
                  present in the HIP header

   TO:I header.

   FROM:I         A TO FROM parameter containing the IP address I is
                  present in the HIP header header.

   VIA:RVS        A VIA_RVS parameter containing the IP addresses of an
                  RVS is present in the HIP header

   EREQ         An ECHO_REQUEST parameter is present in the HIP header

   EREP         An ECHO_REPLY parameter is present in the HIP header

   RREQ header.

   REG_REQ        A REG_REQUEST parameter is present in the HIP header

   RRES header.

   REG_RES        A REG_RESPONSE parameter is present in the HIP header

   RVR:t1,t2    A RVR_TYPE parameter with Type value t1 and t2 is present
                in the HIP header.

3.2  Rendezvous Client Registering with a Rendezvous Server Registration

   Before the Rendezvous Server a rendezvous server starts to relay HIP packets to their
   receiver HIT owner (i.e. a Rendezvous Client or one of its
   correspondent node),
   rendezvous client, the Rendezvous Client rendezvous client needs to register with its
   Server for it to
   receive rendezvous service by using the Rendezvous Service, HIP registration extension
   [2] as shown illustrated in the following schema:

                 +-----+                            +-----+
                 |     |            I1              |     |
                 |     |--------------------------->|     |
                 |     |<---------------------------|     |
                 | RVC  I  |    R1(REG_INFO,RVR:1,2)         R1(REG_INFO)       | RVS |
                 |     |      I2(REG_REQ,RVR:2)         I2(REG_REQ)        |     |
                 |     |--------------------------->|     |
                 |     |<---------------------------|     |
                 |     |      R2(REG_RES,RVR:2)         R2(REG_RES)        |     |
                 +-----+                            +-----+

3.3  Establishing HIP Associations via Rendezvous Servers

3.3.1  Encapsulating I1 into a Tunnel  Relaying the Base Exchange

   If a HIP node and one of its Rendezvous Servers rendezvous servers have a Rendezvous
   Registration rendezvous
   registration, the rendezvous servers MUST relay inbound I1 packets
   that contain one of type TUNNEL_I1, the Rendezvous Server tunnels up to
   this node I1s incoming to this node's HIT using client's HITs by rewriting the appropriate
   encapsulation technique.  The technique to be used is determined
   based on IP header.
   They replace the kind destination IP address of association established between the RVS and its
   client, and differs only by I1 packet with one of
   the type IP addresses of header prepended the owner of the HIT, i.e., the rendezvous
   client.  They MUST also recompute the IP checksum accordingly.

   Because of egress filtering on the path from the RVS to the client, a
   HIP
   packet (e.g.  HIP, ESP or UDP).

                                          ENCAP(RVS, R)[ I1(I, RVS,    ]
                                                       [ HIT-I, HIT-R, ]
    I1(I, RVS, HIT-I, HIT-R) +---------+               [ FROM:I)       ]
    +----------------------->|         |--------------------+
    |                        |   RVS   |                    |
    |                        |         |                    |
    |                        +---------+                    |
    |                                                       V
   +-----+    R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS)    +-----+
   |     |<---------------------------------------------|     |
   |     |                                              |     |
   |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
   |     |--------------------------------------------->|     |
   |     |<---------------------------------------------|     |
   +-----+             R2(R, I, HIT-R, HIT-I)           +-----+

 Figure 5: I1_TUNNEL: Rendezvous Server Encapsulating I1 into a Tunnel

3.3.2  Rewriting I1 IP Header

   If a HIP node and one of its Rendezvous Servers have a Rendezvous
   Registration of type REWRITE_I1, the Rendezvous Server relays up to
   this node I1s incoming to this node's HIT by merely rewrite the IP
   header.  The destination IP address of the I1 is replaced by the IP
   address of the receiver HIT owner (i.e.  the Rendezvous Client).

   However, because of egress filtering, a HIP Rendezvous Server might rendezvous server MAY also need to replace the original source IP address,
   i.e., the IP address of an I1 by I, with one of its own IP address, thus concealing the Initiator's addresses.  The
   replacement IP address SHOULD be chosen according to [6] and, when
   IPv6 is used,  to [7].  Because this replacement conceals the
   Responder.  Hence, such a node
   initiator's IP address, the RVS MUST append I1 packets with a FROM parameter
   containing the original source IP address of the packet.  This FROM
   parameter MUST be integrity protected by a RVR_HMAC RVS_HMAC keyed with the
   corresponding rendezvous registration integrity key [2].

                                             I1(I, RVS,

                                               I1(RVS, R, HIT-I, HIT-R
         I1(I, RVS, HIT-I, HIT-R) +---------+     HIT-R,     FROM:I, VIA:RVS)
         +----------------------->|         |--------------------+
         |                        |   RVS   |                    |
         |                        |         |                    |
         |                        +---------+                    |
         |                                                       V
        +-----+     R1(R, I, HIT-R, HIT-I, REA:R, LOC:R, VIA:RVS)   +-----+
        |     |<---------------------------------------------|     |
        |     |                                              |     |
        |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
        |     |--------------------------------------------->|     |
        |     |<---------------------------------------------|     |
        +-----+             R2(R, I, HIT-R, HIT-I)           +-----+

            Figure 6: I1_REWRITE: 5: Rendezvous Server Rewriting I1 Source and
                        Destination server rewriting IP Addresses

3.3.3  Bidirectional Forwarding addresses
   This modification of HIP packets

   In some cases it is useful to have at a RVS which relay further rendezvous server can be
   problematic.  The HIP
   packets in protocol uses two kinds of packet integrity
   checks: hop-by-hop and end-to-end.  The HIP checksum is a bidirectional manner, i.e.  from the initiator to the
   responder but also from the responder to the initiator.  These
   further packets would typically hop-by-hop
   check and SHOULD be either an R1 or an UPDATE.  A RVS
   behaves accordingly when verified and recomputed by each of the Rendezvous Registration Type is
   BIDIRECTIONAL.

   However, because on-path
   HIP-enabled middleboxes, such packets as rendezvous servers.  The HMAC and
   SIGNATURE are larger than I1 (they contain a
   signature), their relaying create an opportunity for denial of
   service attacks.  To defend against these attacks, the Rendezvous
   Server needs to differentiate between legitimate HIP packets (i.e.,
   I1 end-to-end checks and subsequent HIP packets triggered MUST be computed by an I1) the sender
   and illegitimate
   ones.

   For verified by the receiver.

   The RVS MUST verify the sake checksum field of reducing an I1 packet doing any
   modifications.  After modification, it MUST recompute the load incurred on checksum
   field using the RVS, an RVS is not
   required to keep track of IP addresses and other pieces of state
   associated with ongoing updated HIP exchanges.  Such behavior is OPTIONAL.
   Instead, the relaying facility SHOULD make use of ECHO_REQUEST header, which possibly included new FROM
   and RVS_HMAC parameters, and
   ECHO_RESPONSE parameters.

   Each time a packet is being relayed pseudo-header containing the updated
   source and will possibly trigger an
   answer, destination IP addresses.  This enables the RVS responder to
   validate the checksum of the I1 packet "as is", without having to
   parse any FROM parameters.

   The SIGNATURE and HMAC verification MUST augment it with NOT cover any FROM and
   RVS_HMAC parameters added by rendezvous servers.  Hence, HMAC and
   SIGNATURE are unaffected by the modifications performed by an ECHO_REQUEST parameter
   containing a chunk of opaque data. RVS.
   The receiver computation and verification of such HMAC and SIGNATURE MUST only
   cover the original HIP header with a packet checksum field set to zero, MUST augment
   NOT cover the pseudo header that contains modified IP addresses, and
   mUST NOT cover any packet answering new FROM and RVS_HMAC parameters that MAY be
   situated after the HMAC and SIGNATURE in the HIP header.

4.  Rendezvous Server Extensions

   The following sections describe extensions to this packet the HIP registration
   protocol [2], allowing a HIP node to register with an ECHO_REPLY
   parameter containing a rendezvous
   server for rendezvous service and notify the same chunk RVS aware of opaque data.  This opaque data
   allows changes to
   its current location.  It also describes an RVS extension to find and validate the answered packet IP addresses
   and HITs.  When successfully validated, ECHO_REPLY parameters MUST be
   removed from the packet before relaying.

       I1(I, RVS,                    I1(RVS, R, HIT-I, HIT-0
          HIT-I, HIT-0)   +---------+   FROM:I, EREQ)
    +-------------------->|         |----------------------+
    |+--------------------|         |<--------------------+|
    || R1(RVS, I, HIT-R,  |   RVS   | R1(R, RVS, HIT-R,   ||
    ||    HIT-I, REA:R,   |         |    HIT-I, REA:R,    ||
    ||    VIA:RVS)        |         |    TO:I, EREP)      ||
    ||                    |         |                     ||
    ||                    +---------+                     ||
    |V                                                    |V
   +-----+             I2(R, I, HIT-R, HIT-I)          +-----+
   |     |-------------------------------------------->|     |
   |  I  |<--------------------------------------------|  R  |
   |     |             R2(I, R, HIT-I, HIT-R)          |     |
   +-----+                                             +-----+

  Figure 7: BIDIRECTIONAL: Responder replying via the RVS to Initiator

3.3.4  Implication on the HIP integrity checks

   The
   protocol [4] itself, allowing establishment of HIP associations via
   one or more Rendezvous
   Servers causes HIP packets flowing between the HIP nodes to be
   modified during transmission.  Several kinds of modifications to both
   the IP and HIP headers are possible.  The HIP protocol uses two kinds
   of packet integrity checks: hop-by-hop and end-to-end.  The HIP
   checksum is a hop-by-hop check and SHOULD be verified and recomputed
   by each of the on-path HIP middle-boxes (e.g., Rendezvous Servers).
   The HMAC and SIGNATURE are end-to-end checks and MUST be computed by
   the sender and verified by the receiver.

3.3.4.1  Checksum

   The checksum field of a HIP header to be modified MUST be verified
   before applying the modification and recomputed accordingly after.

3.3.4.2  HMAC and SIGNATURE

   The HMAC and SIGNATURE field of a HIP header MUST be computed and
   verified based on a "sender view" or "receiver view" of the HIP
   header.  In particular, this implies that SIGNATURE and HMAC MUST NOT
   cover FROM and TO parameters added or removed by Rendezvous Servers
   and that the HIP pseudo-header used to compute and verify them MUST
   contain the IP addresses as seen by the remote HIP peer.  In case of
   IP address concealment by the RVS, this means that the IP address of
   this RVS MUST be used in the pseudo-header in place of the IP address
   of the end host it conceals.

3.3.4.3  Example

   Here is an example showing how to compute the different integrity
   checks (end-to-end and hop-by-hop) when two Rendezvous Servers are
   cascaded and conceals the Responder IP address (packet flowing along
   the path I -> RVS1 -> RVS2 -> R)

   End-to-end integrity checks: HMAC and SIGNATURE are computed with a
   pseudo-header containing RVS1 as a place holder for the destination
   IP address, the rationale being that RVS1 is concealing the Responder
   IP address.  Therefore, R will verify the signature using RVS1 as the
   destination IP address in the pseudo-header.

   Hop-by-hop integrity checks: Checksum is computed hop-by-hop; first
   with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and
   R.

4.  RVS Extensions Definition

   The following sections describe extensions to:

   o  The HIP registration protocol [2], allowing a HIP node to register
      with its Rendezvous Server for the Rendezvous Service and maintain
      the RVS aware of its current location.

   o  The HIP protocol [4] itself, allowing to establish an HIP
      association via one or more HIP Rendezvous Server(s).

4.1  Usage and Processing of Existing Parameters

4.1.1  ECHO_REQUEST and ECHO_REPLY Parameters

   A FROM parameter MAY be augmented by including an ECHO_REQUEST
   parameter to the carrying packet.  The contents of the ECHO_REQUEST
   MUST then be echoed back in ECHO_RESPONSE.

   A TO parameter MUST be augmented and authenticated by including an
   ECHO_REPLY parameter to the carrying packet.  The contents of the
   ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE.

   All the HIP packets requiring RVS relaying facility to carry an
   answer packet MUST be augmented by the RVS with an ECHO_REQUEST
   parameter.

   A possible packet answered via the RVS, thus requiring relaying
   facility, MUST be authenticated by an ECHO_REPLY parameter.  The
   contents of the ECHO_REPLY MUST be copied from a previously received
   ECHO_RESPONSE.

   On the receiving side, when a HIP node validates an ECHO_REPLY
   located after the signatures, it MUST remove it from the packet and
   recompute packet length and checksum accordingly.

4.1.2  REA Parameter

   A HIP node associated via an RVS MAY use a REA parameter to make its
   correspondent aware of its veritable current IP address.  If used,
   the REA parameter MUST be used in conformance with the guidelines
   specified in [5].

4.2  New Registration Type

   This specification defines an additional Registration Type to use
   within the HIP Registration protocol [2] while registering with a
   Rendezvous Server for the Rendezvous Service.

   Number Registration Type
   ------ -----------------
   1      RENDEZVOUS

4.3  New Parameter Formats and Processing

4.3.1  RVR_TYPE Parameter

   The RVR_RYPE is an OPTIONAL parameter allowing a Rendezvous Server
   and its Requesters to negotiate the type of Rendezvous Service
   provided by a Rendezvous Registration.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  RVR Type #1  |  RVR Type #2  |                               |
     +-+-+-+-+-+-+-+-+---------------+        Padding                |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type         [ TBD by IANA {110) ]
   Length       8
   RVR Type An 8 bit number indicating the specific type of the
   Rendezvous Server/Service.

      Number RVR Type       Definition

      ------ -------------  -----------------------

      1      TUNNEL_I1      Tunneling I1 - Section 3.3.1

      2      REWRITE_I1     Rewriting I1 - Section 3.3.2

      3      BIDIRECTIONAL  Rewriting I1 and followers - Section 3.3.3

      3-200     Reserved by IANA

      201-255   Reserved by IANA for private use

   A Requester of a Rendezvous Registration SHOULD include the RVR_RYPE
   parameter along with any REG_REQUEST for the Rendezvous Service.
   This parameter specifies the desired RVS Type (i.e.  TUNNEL_I1,
   REWRITE_I1 or BIDIRECTIONAL).  It SHOULD NOT include the parameter
   unless there is a REG_REQUEST parameter included along.

   A Rendezvous Server SHOULD include a RVR_TYPE parameter along with
   any REG_INFO announcing support for the Rendezvous Service.  This
   parameter SHOULD specify all the RVR Types supported by the
   Rendezvous Server, in preference order.

   A Rendezvous Server MUST include a RVR_RYPE parameter along with any
   REG_RESPONSE establishing a Rendezvous Registration.  This parameter
   MUST specify a single RVR Type for the established Registration.

   A Rendezvous Server SHOULD NOT include the parameter unless there is
   a REG_INFO or REG_REQUEST parameter included along.

4.3.2  RVR_HMAC Parameter

   The RVR_HMAC is an OPTIONAL parameter whose only difference with the
   HMAC parameter defined in [4] is the Type code, making it situated
   after the TO and FROM parameters (as opposed to HMAC):

   Type         [ TBD by IANA {65320) ]
   Length       20
   HMAC         160 low order bits of a HMAC keyed with the appropriate
                HIP integrity keys (HIP_lg or HIP_gl) of the corresponding
                HIP Association. This HMAC is computed over the HIP packet
                excluding RVR_HMAC and any other following parameter.
                The checksum field MUST be set to zero and the HIP header
                length in the HIP common header MUST be calculated not to
                cover any excluded parameter when the Authenticator field
                is calculated.

   To allow a Rendezvous Client and its RVS to verify the integrity of
   packets flowing between them, both use an RVR_HMAC parameter keyed
   with a HMAC of HIP_lg and HIP_gl integrity keys.  One RVR_HMAC SHOULD
   be present on every packets flowing between a client and a server and
   MUST be present when FROM and TO parameters are processed.

   On the receiving side, when an RVR_HMAC is validated, it SHOULD be
   removed from the packet and if so, packet length and checksum MUST be
   recomputed accordingly.

4.3.3  FROM Parameter

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Address                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type         [ TBD by IANA {65100 under signature, 65300 after) ]
   Length               16
   Address              An IPv6 address or an IPv4-in-IPv6 format IPv4 address

   A Rendezvous Server MAY add a FROM parameter containing the original
   source IP address of a HIP packet whose source IP address has been
   rewritten.  If one or more FROM parameters are already present, the
   new FROM parameter MUST be appended after the existing ones.

   Each time HIP rendezvous server(s).

4.1  LOCATOR Parameter

   A HIP responder contacted via an RVS inserts MAY use a FROM parameter, it MUST also insert an
   RVR_HMAC protecting LOCATOR parameter in
   the R1 packet integrity that the Rendezvous Client
   will use to validate this packet.

   If notify the type initiator of the RVR allows the Rendezvous Client to answer to a
   relayed packet via the RVS, an ECHO_REQUEST MUST be included along its current IP address, in
   conformance with the FROM parameter.  It contains a chunk of opaque data allowing
   to validate TO parameters included guidelines specified in a subsequent answer.  These TO
   parameters MUST be protected by [5].

4.2  RENDEZVOUS Registration Type

   This specification defines an ECHO_RESPONSE containing additional registration for the same
   opaque data.

   When a HIP node validates
   registration protocol [2] that allows registering with a FROM parameter, it is removed from the
   packet and recorded for later use (i.e., rendezvous
   server for building rendezvous service.

   Number   Registration Type
   ------   -----------------
   1        RENDEZVOUS

4.3  New Parameter Formats and Processing

4.3.1  RVS_HMAC Parameter

   The RVS_HMAC is an OPTIONAL parameter whose only difference with the
   corresponding TO
   HMAC parameter defined in [4] is its "type" code.  This change causes
   it to be piggy-backed onto a subsequent
   answer).  The packet's source IP address is also replaced by located after the
   address included in FROM parameter (as opposed to the first occurrence HMAC):

   Type        [ TBD by IANA (65472 = 2^16 - 2^6) ]
   Length      20
   HMAC        160 low order bits of FROM parameter.

   For each FROM parameter, a HMAC keyed with the
               appropriate HIP node MAY add to its replies a TO
   parameter containing integrity key (HIP_lg or HIP_gl),
               established when rendezvous registration happened.
               This HMAC is computed over the IP address included in HIP packet, excluding
               RVS_HMAC and any following parameters. The
               "checksum" field MUST be set to zero and the FROM.  These
   replies will be sent via HIP header
               length in the RVS, which HIP common header MUST remove the outer TO be calculated
               not to cover any excluded parameter from when the packet
               "authenticator" field is calculated.

   To allow a rendezvous client and replace its destination address with
   the address contained in RVS to verify the TO integrity of
   packets flowing between them, both SHOULD protect packets with an
   added RVS_HMAC parameter before relaying it.

4.3.4  TO keyed with the HIP_lg or HIP_gl integrity
   key.  A valid RVS_HMAC SHOULD be present on every packets flowing
   between a client and a server and MUST be present when a FROM
   parameters is processed.

4.3.2  FROM Parameter

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Type              |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                             Address                           |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type        [ TBD by IANA {65102 under signature, 65302 after) (65470 = 2^16 - 2^6 - 2) ]
    Length      16
    Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address address.

   A HIP node MAY rendezvous server MUST add one or more TO a FROM parameter containing the final
   destination original
   source IP address of a HIP packet whose destination whenever the source IP address
   needs to be rewritten by an RVS.  This in
   the IP header is essentially equivalent to
   loose source-routing. rewritten.  If one or more TO FROM parameters are
   already present, the new TO FROM parameter MUST be appended after the
   existing ones.  Each time a node

   Whenever an RVS inserts a TO FROM parameter, it MUST also insert
   additional parameters that will be used by the RVS for validation.
   These parameters are:

   o  An ECHO_RESPONSE, containing a chunk of opaque data allowing the
      RVS to validate the address contained in the TO parameter.

   o  A valid RVR_HMAC, protecting the packet integrity.

   When the RVS validates a TO parameter, SHALL remove it from the
   packet, and SHALL replace the packet destination IP address with the
   address included in the TO parameter.  Packet length and checksum
   MUST then be recomputed accordingly.

   For each FROM parameter, a HIP node MAY add to its replies a TO
   parameter containing the IP address included in the FROM.  These
   replies will be sent via the RVS, which MUST remove the outer TO
   parameter from the packet and replace its destination address field
   with an RVS_HMAC
   protecting the packet integrity, especially the IP address contained included
   in the TO parameter before relaying it.

4.3.5 FROM parameter.

4.3.3  VIA_RVS Parameter

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                               .                               .
     .                               .                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA {65500) (65474 = 2^16 - 2^6 + 2) ]
     Length      Variable
     Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address

   At some point a, HIP endpoint might be in position to

   After the responder receives a relayed I1 packet, it can begin to
   send HIP packets directly towards addressed to the remote HIP endpoint's initiator's IP address, without
   further assistance from one or more of its RVS(s).  In that
   case, an RVS.  For debugging purposes, it MAY
   include in these packets a subset of the IP address(es) addresses of its RVSs in some of these
   packets.  When a responder does so, it MUST append a newly created
   VIA_RVS parameter at the end of the HIP packet.  The main goal of
   using the VIA_RVS parameter is to allow operators to diagnose
   possible issues encountered while establishing a HIP association via
   a RVS.

4.4  Processing Outgoing I1 Packets

   An initiator SHOULD not send an opportunistic I1 with a NULL
   destination HIT to an IP address which is known to be a rendezvous
   server address, unless it wants to establish a HIP association with
   the rendezvous server itself and does not know its HIT.

   If an RVS needs to rewrite the source IP address of an I1 packet due
   to egress filtering, then it MUST add a FROM parameter to the I1 that
   contasins the initiator's source IP address.  This FROM parameter
   MUST be protected by a RVS_HMAC keyed with the integrity key
   established at rendezvous registration.

4.5  Processing Incoming I1 packets

   When a rendezvous server receives an I1 whose destination HIT is not
   its own, it MUST consult its registration database to find a
   registration for debugging purposes.

   Similarly, the rendezvous service established by the HIT owner.
   If it finds an appropriate registration, it MUST relay the packet to
   the registered IP address.  If it does not find an appropriate
   registration, is MUST drop the packet.

   A rendezvous server SHOULD interpret any incoming opportunistic I1
   (i.e., an I1 with a RVS relaying NULL destination HIT) as an I1 addressed to the Responder or an R1
   itself and SHOULD NOT attempt to the
   Initiator MAY include in these packets its IP address for debugging
   as well.

   When the IP address of a RVS need relay it to be included in a packet, by
   either an end-node or the RVS itself, one of these two methods is
   used:

   o  Add RVS IP address into its clients.

   When a rendezvous client receives an existing VIA_RVS parameter situated at
      the end of I1, it MUST validate any present
   RVS_HMAC parameter.  If the HIP packet, while modifying accordingly RVS_HMAC cannot be verified, the size of packet
   SHOULD be dropped.  If the parameter.

   o  Append RVS_HMAC cannot be verified and a newly created VIA_RVS FROM
   parameter at the end of is present, the HIP packet if it does not already contain MUST be dropped.

   A rendezvous client acting as responder SHOULD drop opportunistic I1s
   that include a VIA_RVS parameter.

   Note FROM parameter, because this indicates that the main goal of using the VIA_RVS parameter is to allow
   operators to diagnose possible issues encountered while establishing
   a HIP association via a RVS. I1 has
   been relayed.

5.  Security Considerations

   The security aspects of different HIP rendezvous mechanisms are
   currently being investigated.  This section describes the known
   threats introduced by these HIP extensions, extensions and implications on the
   overall security of HIP and IP.  In particular, the following tries
   to show it argues that the
   extensions described in this document do not introduce additional
   threats in to the Internet infrastructure.

   It is difficult to encompass the whole scope of threats introduced by
   Rendezvous Servers
   rendezvous servers, because their presence have has implications both at
   the IP and HIP layer. layers.  In particular, the these extensions hereby described might allow
   for redirection, amplification and reflection attacks at the IP
   layer, as well as attacks on the HIP layer itself, for example
   Man-in-the-Middle example, man-
   in-the-middle attacks against the cryptographic core-protocol HIP's SIGMA used by HIP. protocol.

   If an Initiator initiator has an a priori knowledge of the Responder's HI responder's host
   identity when it first contacts it via the an RVS, it has a means to
   verify the signatures in the HIP exchange, thus conforming to the
   SIGMA protocol which is resilient to Man-in-the-Middle man-in-the-middle attacks.

   If an Initiator has initiator does not an have a priori knowledge of the Responder's HI
   (so called Opportunistic Initiators), responder's
   host identiy (so-called "opportunistic initiators"), it is almost
   impossible to defend the HIP exchange against MitM attacks (cannot authenticate these attacks, because
   the public keys exchanged). exchanged cannot be authenticated.  The only solution is approach
   would be to mitigate hijacking threats on the HIP state by requiring an
   R1 answering an
   Opportunistic opportunistic I1 to come from the same IP address where
   that originally sent the I1 was
   initially sent.  That way we retain I1.  This procedure retains a level of
   security which is equivalent to what exists today in the Internet: By sending an IP
   packet to an IP address, and receiving an answered IP packet from
   this same IP address, I know that the routing fabric trusts my
   correspondent to be represented by Internet today.

   However, for reasons of simplicity, this IP address.  While it is true
   that such security is weak, it is better than none, and avoids specification does not allow
   to
   introduce additional threats at the IP layer. establish a HIP association via a rendezvous server in an
   opportunistic manner.

6.  IANA Considerations

   This section is to be interpreted according to [8].

   This document updates the IANA Registry for HIP Parameters Types by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in Section 4.3:

   o  RVR_TYPE  RVS_HMAC (defined in Section 4.3.1)

   o  RVR_HMAC (defined in Section 4.3.2)
   o  FROM (defined in Section 4.3.3)

   o  TO (defined in Section 4.3.4) 4.3.2)

   o  VIA_RVS (defined in Section 4.3.5)

   IANA needs to open a new registry specific to the HIP Rendezvous
   Extensions, for the Rendezvous Registration (RVR) Types values
   defined in Section 4.3.1:

      Type number       RVR Type

      -----------       --------

      0         Reserved by IANA

      1         TUNNEL_I1

      2         REWRITE_I1

      3         BIDIRECTIONAL

      3-200     Reserved by IANA

      201-255   Reserved by IANA for private use

   Adding new reservations requires IETF consensus RFC2434 [7]. 4.3.3)

7.  Acknowledgments

   The following people have provided thoughtful and helpful discussions
   and/or suggestions that have improved this document: Marcus Brunner,
   Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino
   Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Stiemerling,
   Stiemerling and Juergen Quittek.

   Part of this work

   Lars Eggert is a product of the partly funded by Ambient Networks project,
   partially Networks, a research project
   supported by the European Commission under its Sixth Framework Programme.  It is provided "as is" and without any express
   or implied warranties, including, without limitation, the implied
   warranties of fitness for a particular purpose.
   Program.  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the Ambient Networks project or the European Commission.

8.  References

8.1  Normative References

   [1]  Moskowitz, R. and P. Nikander, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-00
        draft-ietf-hip-arch-02 (work in progress),
        October 2004. January 2005.

   [2]  Laganier, J.,  Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
        Registration Extensions", Extension", draft-koponen-hip-registration-00 (work
        in progress), January February 2005.

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

   [4]  Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity Protocol", draft-ietf-hip-base-01 draft-ietf-hip-base-02
        (work in progress), October
        2004. February 2005.

   [5]  Nikander, P., "End-Host Mobility and Multi-Homing with Host
        Identity Protocol", draft-ietf-hip-mm-00 draft-ietf-hip-mm-01 (work in progress),
        October 2004.

8.2  Informative References
        February 2005.

   [6]   Saltzer, J., "On the Naming and Binding of Network
         Destinations",  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1498, August 1993. 1122, October 1989.

   [7]  Draves, R., "Default Address Selection for Internet Protocol
        version 6 (IPv6)", RFC 3484, February 2003.

   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [8]

8.2  Informative References

   [9]   Saltzer, J., "On the Naming and Binding of Network
         Destinations", RFC 1498, August 1993.

   [10]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

   [12]  Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
         Domain Name System (DNS) Extensions", draft-ietf-hip-rvs-00 draft-ietf-hip-dns-01
         (work in progress), October 2004.

   [9] February 2005.

   [13]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [10]

   [14]  Killalea, T., "Recommended Internet Service Provider Security
         Services and Procedures", BCP 46, RFC 3013, November 2000.

Editorial Comments

   [Comment.1]  In this specification the client of the RVS is always
                the responder.  However, there might be reasons to allow
                a client to initiate a base exchange through its own
                RVS, like NAT and firewall traversal. This specification
                does not address such scenarios which should be
                specified in other documents.

Authors' Addresses

   Julien Laganier
   Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL)
   180, Avenue de l'Europe
   Saint Ismier CEDEX  38334
   FR
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +33 476 188 815
   EMail: ju@sun.com +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://research.sun.com/   http://www.docomolab-euro.com/

   Lars Eggert
   NEC Network Laboratories
   Kurfuersten-Anlage
   Kurfuerstenanlage 36
   Heidelberg  69115
   DE
   Germany

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   EMail:
   Email: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/

Appendix A.  Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 02        | Removed multiple relaying techniques but simple I1    |
   |           | header rewriting. Updated new HIP parameters type     |
   |           | numbers (consistent with new layout and assigning     |
   |           | rules from draft-ietf-hip-base.) Updated IANA         |
   |           | Considerations.                                       |
   | 01        | Splitted out the registration sub-protocol. Simplify  |
   |           | typology of relaying techniques (keep only TUNNEL,    |
   |           | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
   | 00        | Initial version as a HIP WG item.                     |
   +-----------+-------------------------------------------------------+

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.