doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5204.txt b/doc/rfc/rfc5204.txt
new file mode 100644
index 0000000..7bea1a8
--- /dev/null
+++ b/doc/rfc/rfc5204.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        J. Laganier
+Request for Comments: 5204                              DoCoMo Euro-Labs
+Category: Experimental                                         L. Eggert
+                                                                   Nokia
+                                                              April 2008
+
+
+           Host Identity Protocol (HIP) Rendezvous Extension
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document defines a rendezvous extension for the Host Identity
+   Protocol (HIP).  The rendezvous extension extends HIP and the HIP
+   registration extension for initiating communication between HIP nodes
+   via HIP rendezvous servers.  Rendezvous servers improve reachability
+   and operation when HIP nodes are multi-homed or mobile.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 1]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Overview of Rendezvous Server Operation  . . . . . . . . . . .  4
+     3.1.  Diagram Notation . . . . . . . . . . . . . . . . . . . . .  5
+     3.2.  Rendezvous Client Registration . . . . . . . . . . . . . .  6
+     3.3.  Relaying the Base Exchange . . . . . . . . . . . . . . . .  6
+   4.  Rendezvous Server Extensions . . . . . . . . . . . . . . . . .  7
+     4.1.  RENDEZVOUS Registration Type . . . . . . . . . . . . . . .  7
+     4.2.  Parameter Formats and Processing . . . . . . . . . . . . .  8
+       4.2.1.  RVS_HMAC Parameter . . . . . . . . . . . . . . . . . .  8
+       4.2.2.  FROM Parameter . . . . . . . . . . . . . . . . . . . .  9
+       4.2.3.  VIA_RVS Parameter  . . . . . . . . . . . . . . . . . . 10
+     4.3.  Modified Packets Processing  . . . . . . . . . . . . . . . 10
+       4.3.1.  Processing Outgoing I1 Packets . . . . . . . . . . . . 10
+       4.3.2.  Processing Incoming I1 Packets . . . . . . . . . . . . 11
+       4.3.3.  Processing Outgoing R1 Packets . . . . . . . . . . . . 11
+       4.3.4.  Processing Incoming R1 Packets . . . . . . . . . . . . 11
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 2]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+1.  Introduction
+
+   The Host Identity Protocol (HIP) Architecture [RFC4423] introduces
+   the rendezvous mechanism to help a HIP node to contact a frequently
+   moving HIP node.  The rendezvous mechanism involves a third party,
+   the rendezvous server (RVS), which serves as an initial contact point
+   ("rendezvous point") for its clients.  The clients of an RVS are HIP
+   nodes that use the HIP Registration Extension [RFC5203] to register
+   their HIT->IP address mappings with the RVS.  After this
+   registration, other HIP nodes can initiate a base exchange using the
+   IP address of the RVS instead of the current IP address of the node
+   they attempt to contact.  Essentially, the clients of an RVS become
+   reachable at the RVS's IP address.  Peers can initiate a HIP base
+   exchange with the IP address of the RVS, which will relay this
+   initial communication such that the base exchange may successfully
+   complete.
+
+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 [RFC2119].
+
+   In addition to the terminology defined in the HIP specification
+   [RFC5201] and the HIP Registration Extension [RFC5203], this document
+   defines and uses the following terms:
+
+   Rendezvous Service
+      A HIP service provided by a rendezvous server to its rendezvous
+      clients.  The rendezvous server offers to relay some of the
+      arriving base exchange packets between the initiator and
+      responder.
+
+   Rendezvous Server (RVS)
+      A HIP registrar providing rendezvous service.
+
+   Rendezvous Client
+      A HIP requester that has registered for rendezvous service at a
+      rendezvous server.
+
+   Rendezvous Registration
+      A HIP registration for rendezvous service, established between a
+      rendezvous server and a rendezvous client.
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 3]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+3.  Overview of Rendezvous Server Operation
+
+   Figure 1 shows a simple HIP 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's IP address,
+   as per the HIP specification [RFC5201].
+
+                       +-----+                +-----+
+                       |     |-------I1------>|     |
+                       |  I  |<------R1-------|  R  |
+                       |     |-------I2------>|     |
+                       |     |<------R2-------|     |
+                       +-----+                +-----+
+
+          Figure 1: HIP base exchange without rendezvous server.
+
+   The End-Host Mobility and Multihoming with the Host Identity Protocol
+   specification [RFC5206] allows a HIP node to notify its peers about
+   changes in its set of IP addresses.  This specification presumes
+   initial reachability of the two nodes with respect to each other.
+
+   However, such a HIP node MAY also want to be reachable to other
+   future correspondent peers that are unaware of its location change.
+   The HIP Architecture [RFC4423] introduces rendezvous servers with
+   whom a HIP node MAY register its host identity tags (HITs) and
+   current IP addresses.  An RVS relays HIP packets arriving for these
+   HITs to the node's registered IP addresses.  When a HIP node has
+   registered with an RVS, it SHOULD record the IP address of its RVS in
+   its DNS record, using the HIP DNS resource record type defined in the
+   HIP DNS Extension [RFC5205].
+
+                                   +-----+
+                          +--I1--->| RVS |---I1--+
+                          |        +-----+       |
+                          |                      v
+                       +-----+                +-----+
+                       |     |<------R1-------|     |
+                       |  I  |-------I2------>|  R  |
+                       |     |<------R2-------|     |
+                       +-----+                +-----+
+
+           Figure 2: HIP base exchange with a rendezvous server.
+
+   Figure 2 shows a HIP base exchange involving a rendezvous server.  It
+   is assumed that HIP node R previously registered its HITs and current
+   IP addresses with the RVS, using the HIP Registration Extension
+   [RFC5203].  When the initiator I tries to establish contact with the
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 4]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+   responder R, it must send the I1 of the base exchange either to one
+   of R's IP addresses (if known via DNS or other means) or to one of
+   R's rendezvous servers.  Here, I obtains the IP address of R's
+   rendezvous server from R's DNS record and then sends the I1 packet of
+   the HIP base exchange to RVS.  RVS, noticing that the HIT contained
+   in the arriving I1 packet is not one of its own, MUST check its
+   current registrations to determine if it needs to relay the packets.
+   Here, it determines that the HIT belongs to R and then relays the I1
+   packet to the registered IP address.  R then completes the base
+   exchange without further assistance from RVS by sending an R1
+   directly to the I's IP address, as obtained from the I1 packet.  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.
+
+3.1.  Diagram Notation
+
+  Notation       Significance
+  --------       ------------
+
+  I, R           I and R are the respective source and destination IP
+                 addresses in the IP header.
+
+  HIT-I, HIT-R   HIT-I and HIT-R are the initiator's and the
+                 responder's HITs in the packet, respectively.
+
+  REG_REQ        A REG_REQUEST parameter is present in the HIP header.
+
+  REG_RES        A REG_RESPONSE parameter is present in the HIP header.
+
+  FROM:I         A FROM parameter containing the IP address I is
+                 present in the HIP header.
+
+  RVS_HMAC       An RVS_HMAC parameter containing an HMAC keyed with the
+                 appropriate registration key is present in the HIP
+                 header.
+
+  VIA:RVS        A VIA_RVS parameter containing the IP address RVS of a
+                 rendezvous server is present in the HIP header.
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 5]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+3.2.  Rendezvous Client Registration
+
+   Before a rendezvous server starts to relay HIP packets to a
+   rendezvous client, the rendezvous client needs to register with it to
+   receive rendezvous service by using the HIP Registration Extension
+   [RFC5203] as illustrated in the following schema:
+
+                 +-----+                            +-----+
+                 |     |            I1              |     |
+                 |     |--------------------------->|     |
+                 |     |<---------------------------|     |
+                 |  I  |         R1(REG_INFO)       | RVS |
+                 |     |         I2(REG_REQ)        |     |
+                 |     |--------------------------->|     |
+                 |     |<---------------------------|     |
+                 |     |         R2(REG_RES)        |     |
+                 +-----+                            +-----+
+
+          Rendezvous client registering with a rendezvous server.
+
+3.3.  Relaying the Base Exchange
+
+   If a HIP node and one of its rendezvous servers have a rendezvous
+   registration, the rendezvous servers relay inbound I1 packets (that
+   contain one of the client's HITs) by rewriting the IP header.  They
+   replace the destination IP address of the I1 packet with one of the
+   IP addresses of 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
+   [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
+   IP address, i.e., the IP address of I, with one of its own IP
+   addresses.  The replacement IP address SHOULD be chosen according to
+   relevant IPv4 and IPv6 specifications [RFC1122][RFC3484].  Because
+   this replacement conceals the initiator's IP address, the RVS MUST
+   append a FROM parameter containing the original source IP address of
+   the packet.  This FROM parameter MUST be integrity protected by an
+   RVS_HMAC keyed with the corresponding rendezvous registration
+   integrity key [RFC5203].
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 6]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+                                               I1(RVS, R, HIT-I, HIT-R
+         I1(I, RVS, HIT-I, HIT-R) +---------+     FROM:I, RVS_HMAC)
+         +----------------------->|         |--------------------+
+         |                        |   RVS   |                    |
+         |                        |         |                    |
+         |                        +---------+                    |
+         |                                                       V
+        +-----+        R1(R, I, HIT-R, HIT-I, VIA:RVS)       +-----+
+        |     |<---------------------------------------------|     |
+        |     |                                              |     |
+        |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
+        |     |--------------------------------------------->|     |
+        |     |<---------------------------------------------|     |
+        +-----+             R2(R, I, HIT-R, HIT-I)           +-----+
+
+                 Rendezvous server rewriting IP addresses.
+
+   This modification of HIP packets at a rendezvous server can be
+   problematic because the HIP protocol uses integrity checks.  Because
+   the I1 does not include HMAC or SIGNATURE parameters, these two end-
+   to-end integrity checks are unaffected by the operation of rendezvous
+   servers.
+
+   The RVS SHOULD verify the checksum field of an I1 packet before doing
+   any modifications.  After modification, it MUST recompute the
+   checksum field using the updated HIP header, which possibly included
+   new FROM and RVS_HMAC parameters, and a pseudo-header containing the
+   updated source and destination IP addresses.  This enables the
+   responder to validate the checksum of the I1 packet "as is", without
+   having to parse any FROM parameters.
+
+4.  Rendezvous Server Extensions
+
+   This section describes extensions to the HIP Registration Extension
+   [RFC5203], allowing a HIP node to register with a rendezvous server
+   for rendezvous service and notify the RVS aware of changes to its
+   current location.  It also describes an extension to the HIP
+   specification [RFC5201] itself, allowing establishment of HIP
+   associations via one or more HIP rendezvous server(s).
+
+4.1.  RENDEZVOUS Registration Type
+
+   This specification defines an additional registration for the HIP
+   Registration Extension [RFC5203] that allows registering with a
+   rendezvous server for rendezvous service.
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 7]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+   Number   Registration Type
+   ------   -----------------
+   1        RENDEZVOUS
+
+4.2.  Parameter Formats and Processing
+
+4.2.1.  RVS_HMAC Parameter
+
+   The RVS_HMAC is a non-critical parameter whose only difference with
+   the HMAC parameter defined in the HIP specification [RFC5201] is its
+   "type" code.  This change causes it to be located after the FROM
+   parameter (as opposed to the HMAC):
+
+ Type        65500
+ Length      Variable.  Length in octets, excluding Type, Length, and
+             Padding.
+ HMAC        HMAC computed over the HIP packet, excluding the
+             RVS_HMAC parameter and any following parameters.  The
+             HMAC is keyed with the appropriate HIP integrity key
+             (HIP-lg or HIP-gl) established when rendezvous
+             registration happened.  The HIP "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 HMAC is calculated.  The size of the
+             HMAC is the natural size of the hash computation
+             output depending on the used hash function.
+
+   To allow a rendezvous client and its RVS to verify the integrity of
+   packets flowing between them, both SHOULD protect packets with an
+   added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
+   key established while registration occurred.  A valid RVS_HMAC SHOULD
+   be present on every packet flowing between a client and a server and
+   MUST be present when a FROM parameter is processed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 8]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+4.2.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        65498
+    Length      16
+    Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
+
+   A rendezvous server MUST add a FROM parameter containing the original
+   source IP address of a HIP packet whenever the source IP address in
+   the IP header is rewritten.  If one or more FROM parameters are
+   already present, the new FROM parameter MUST be appended after the
+   existing ones.
+
+   Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
+   protecting the packet integrity, especially the IP address included
+   in the FROM parameter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                      [Page 9]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+4.2.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        65502
+    Length      Variable
+    Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
+
+   After the responder receives a relayed I1 packet, it can begin to
+   send HIP packets addressed to the initiator's IP address, without
+   further assistance from an RVS.  For debugging purposes, it MAY
+   include a subset of the IP 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
+   an RVS.
+
+4.3.  Modified Packets Processing
+
+   The following subsections describe the differences of processing of
+   I1 and R1 while a rendezvous server is involved in the base exchange.
+
+4.3.1.  Processing Outgoing I1 Packets
+
+   An initiator SHOULD NOT send an opportunistic I1 with a NULL
+   destination HIT to an IP address that 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.
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 10]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+   When an RVS rewrites the source IP address of an I1 packet due to
+   egress filtering, it MUST add a FROM parameter to the I1 that
+   contains the initiator's source IP address.  This FROM parameter MUST
+   be protected by an RVS_HMAC keyed with the integrity key established
+   at rendezvous registration.
+
+4.3.2.  Processing Incoming I1 Packets
+
+   When a rendezvous server receives an I1 whose destination HIT is not
+   its own, it consults its registration database to find a registration
+   for the rendezvous service established by the HIT owner.  If it finds
+   an appropriate registration, it relays the packet to the registered
+   IP address.  If it does not find an appropriate registration, it
+   drops the packet.
+
+   A rendezvous server SHOULD interpret any incoming opportunistic I1
+   (i.e., an I1 with a NULL destination HIT) as an I1 addressed to
+   itself and SHOULD NOT attempt to relay it to one of its clients.
+
+   When a rendezvous client receives an I1, it MUST validate any present
+   RVS_HMAC parameter.  If the RVS_HMAC cannot be verified, the packet
+   SHOULD be dropped.  If the RVS_HMAC cannot be verified and a FROM
+   parameter is present, the packet MUST be dropped.
+
+   A rendezvous client acting as responder SHOULD drop opportunistic I1s
+   that include a FROM parameter, because this indicates that the I1 has
+   been relayed.
+
+4.3.3.  Processing Outgoing R1 Packets
+
+   When a responder replies to an I1 relayed via an RVS, it MUST append
+   to the regular R1 header a VIA_RVS parameter containing the IP
+   addresses of the traversed RVSs.
+
+4.3.4.  Processing Incoming R1 Packets
+
+   The HIP specification [RFC5201] mandates that a system receiving an
+   R1 MUST first check to see if it has sent an I1 to the originator of
+   the R1 (i.e., the system is in state I1-SENT).  When the R1 is
+   replying to a relayed I1, this check SHOULD be based on HITs only.
+   In case the IP addresses are also checked, then the source IP address
+   MUST be checked against the IP address included in the VIA_RVS
+   parameter.
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 11]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+5.  Security Considerations
+
+   This section discusses the known threats introduced by these HIP
+   extensions and the implications on the overall security of HIP.  In
+   particular, it argues that the extensions described in this document
+   do not introduce additional threats to the Host Identity Protocol.
+
+   It is difficult to encompass the whole scope of threats introduced by
+   rendezvous servers because their presence has implications both at
+   the IP and HIP layers.  In particular, these extensions 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 attacks against the HIP base exchange.
+
+   If an initiator has a priori knowledge of the responder's host
+   identity when it first contacts the responder via an RVS, it has a
+   means to verify the signatures in the HIP base exchange, which
+   protects against man-in-the-middle attacks.
+
+   If an initiator does not have a priori knowledge of the responder's
+   host identity (so-called "opportunistic initiators"), it is almost
+   impossible to defend the HIP exchange against these attacks, because
+   the public keys exchanged cannot be authenticated.  The only approach
+   would be to mitigate hijacking threats on HIP state by requiring an
+   R1 answering an opportunistic I1 to come from the same IP address
+   that originally sent the I1.  This procedure retains a level of
+   security that is equivalent to what exists in the Internet today.
+
+   However, for reasons of simplicity, this specification does not allow
+   the establishment of a HIP association via a rendezvous server in an
+   opportunistic manner.
+
+6.  IANA Considerations
+
+   This section is to be interpreted according to the Guidelines for
+   Writing an IANA Considerations Section in RFCs [RFC2434].
+
+   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.2:
+
+   o  RVS_HMAC (defined in Section 4.2.1)
+
+   o  FROM (defined in Section 4.2.2)
+
+   o  VIA_RVS (defined in Section 4.2.3)
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 12]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+   This document defines an additional registration for the HIP
+   Registration Extension [RFC5203] that allows registering with a
+   rendezvous server for rendezvous service.
+
+   Number   Registration Type
+   ------   -----------------
+   1        RENDEZVOUS
+
+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, and Juergen Quittek.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
+
+   [RFC5203]  Laganier, J., Koponen, T., and L. Eggert, "Host Identity
+              Protocol (HIP) Registration Extension", RFC 5203,
+              April 2008.
+
+   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
+              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
+              April 2008.
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 13]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+8.2.  Informative References
+
+   [RFC2827]  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.
+
+   [RFC3013]  Killalea, T., "Recommended Internet Service Provider
+              Security Services and Procedures", BCP 46, RFC 3013,
+              November 2000.
+
+   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
+              (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC5206]  Henderson, T., Ed., "End-Host Mobility and Multihoming
+              with the Host Identity Protocol", RFC 5206, April 2008.
+
+Authors' Addresses
+
+   Julien Laganier
+   DoCoMo Communications Laboratories Europe GmbH
+   Landsberger Strasse 312
+   Munich  80687
+   Germany
+
+   Phone: +49 89 56824 231
+   EMail: julien.ietf@laposte.net
+   URI:   http://www.docomolab-euro.com/
+
+
+   Lars Eggert
+   Nokia Research Center
+   P.O. Box 407
+   Nokia Group  00045
+   Finland
+
+   Phone: +358 50 48 24461
+   EMail: lars.eggert@nokia.com
+   URI:   http://research.nokia.com/people/lars_eggert/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 14]
+
+RFC 5204                HIP Rendezvous Extension              April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Eggert             Experimental                     [Page 15]
+