HIPNetwork Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: DecemberJanuary 12, 20052006 L. Eggert NEC June 10,July 11, 2005 Host Identity Protocol (HIP) Rendezvous Extension draft-ietf-hip-rvs-02draft-ietf-hip-rvs-03 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 DecemberJanuary 12, 2005.2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document discussesdefines 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 43 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 65 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 65 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 76 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 87 4.1 LOCATOR ParameterRENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 4.2 Parameter Formats and Processing . . . . . 8 4.2 RENDEZVOUS Registration Type. . . . . . . . 7 4.2.1 RVS_HMAC Parameter . . . . . . . 8 4.3 New Parameter Formats and Processing. . . . . . . . . . . 9 4.3.1 RVS_HMAC7 4.2.2 FROM Parameter . . . . . . . . . . . . . . . . . . 9 4.3.2 FROM Parameter. . 8 4.2.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9 4.3.3 VIA_RVS Parameter . . .4.3 Modified Packets Processing . . . . . . . . . . . . . . . 10 4.49 4.3.1 Processing Outgoing I1 Packets . . . . . . . . . . . . . . 10 4.59 4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10 4.3.3 Processing Outgoing R1 Packets . . 11 5. Security Considerations. . . . . . . . . . 10 4.3.4 Processing Incoming R1 packets . . . . . . . . . 11 6. IANA Considerations. . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments. 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . 12 8. References. . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . 13 8.1 Normative References. . . . . . . . . . . . . . . . . . . 13 8.2 Informative References. . . 12 8.1 Normative References . . . . . . . . . . . . . . . 13 Editorial Comments. . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 1412 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 1413 A. Document Revision History . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 1615 1. Introduction The current Internet uses IP addresses for two purposes. First, they are topological locators for network attachment points. Second, they act as names for the attached network interfaces. Saltzer  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. TheHost Identity Protocol (HIP)architecture  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[I-D.ietf-hip-arch] introduces the HIP layer needsrendezvous mechanism to map Host Identities into IP addresses. Without HIP,help a HIP node needs to know its peer's IP addressto make initial contact.contact a frequently moving HIP node. The Host Identity Protocol architecture  does not change this basic property, but introduces an additional, optional piece of infrastructure,rendezvous mechanism involves a third party, the rendezvous server (RVS). An RVS(RVS), which serves as an additionalinitial contact point ("rendezvous point") for its clients. The clients of an RVS are HIP nodes that use the HIP Registration Protocol [I-D.koponen-hip-registration] 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' IP addresses. 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. 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 update its DNS entry with its current IP address before it becomes reachable to its peers. Although the DNS offers mechanisms for dynamic updates to records, they may not be suitable when a record changes frequently. Caching, state lifetimes and deficiences in existing DNS implementations limit the 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 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 support high-rate updates, this indirection can improve reachability of HIP 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 .[RFC2119]. In addition to the terminology defined in ,[I-D.koponen-hip- registration], 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. [Comment.1]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. 3. Overview of Rendezvous Server Operation HIP decouples domain names from IP addresses. Because transport protocols bind to host identities, they remain unaware if the set of IP addresses associated with a 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 without rendezvous server.Figure 21 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 base specification .[I-D.ietf-hip-base]. +-----+ +-----+ | |-------I1------>| | | I |<------R1-------| R | | |-------I2------>| | | |<------R2-------| | +-----+ +-----+ Figure 1: HIP base exchange without rendezvous server. Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm] allow a HIP node to notify its peers about changes in its set of IP addresses. These extensions require an established HIP association betweenpresumes initial reachability of the two nodes, i.e., a completed HIP base exchange.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 [I-D.ietf-hip-arch] 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 HIPRVS DNS record type defined in .[I-D.ietf-hip-dns]. +-----+ +--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 protocol .[I-D.koponen-hip-registration]. When the initiator I tries to establish contact with the responder R, it MAYmust send the I1 of the base exchange either to one of R's DNSIP addresses (if known via DNS or other means) or it MAY send itto the address ofone of R's rendezvous servers instead. 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 if 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. 3.1 Diagram Notation Notation Significance -------- ------------ I, R I and R areIn this specification the respective source and destination IP addresses inclient 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. LOC:IREG_REQ A LOCATORREG_REQUEST parameter containing the IP address Iis present in the HIP header. FROM:IREG_RES A FROMREG_RESPONSE parameter containing the IP address Iis present in the HIP header. VIA:RVSFROM:I A VIA_RVSFROM parameter containing the IP addresses of an RVSaddress I is present in the HIP header. REG_REQRVS_HMAC A REG_REQUESTRVS_HMAC parameter containing a HMAC keyed with the appropriate registration key is present in the HIP header. REG_RESVIA:RVS A REG_RESPONSEVIA_RVS parameter containing the IP address RVS of a rendezvous server is present in the HIP header. 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 [I-D.koponen-hip-registration] as illustrated in the following schema: +-----+ +-----+ | | I1 | | | |--------------------------->| | | |<---------------------------| | | I | R1(REG_INFO) | RVS | | | I2(REG_REQ) | | | |--------------------------->| | | |<---------------------------| | | | R2(REG_RES) | | +-----+ +-----+ 3.3 Relaying the Base Exchange If a HIP node and one of its rendezvous servers have a rendezvous registration, the rendezvous servers MUSTrelay 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,client [RFC2827][RFC3013], a HIP rendezvous server MAY also need toSHOULD 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 [RFC1122] and, when IPv6 is used, to .[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 a RVS_HMAC keyed with the corresponding rendezvous registration integrity key .[I-D.koponen-hip-registration]. I1(RVS, R, HIT-I, HIT-R I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, VIA:RVS)RVS_HMAC) +----------------------->| |--------------------+ | | RVS | | | | | | | +---------+ | | V +-----+ R1(R, I, HIT-R, HIT-I, LOC:R,VIA:RVS) +-----+ | |<---------------------------------------------| | | | | | | I | I2(I, R, HIT-I, HIT-R) | R | | |--------------------------------------------->| | | |<---------------------------------------------| | +-----+ R2(R, I, HIT-R, HIT-I) +-----+ Figure 5: Rendezvous server rewriting IP addressesThis modification of HIP packets at a rendezvous server can be problematic. Theproblematic because the HIP protocol uses two kinds of packetintegrity 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 ofchecks. Because the on-path HIP-enabled middleboxes, such as rendezvous servers. TheI1 does not include HMAC andor SIGNATURE are end-to-endparameters, these two end- to-end integrity checks and MUST be computed by the sender and verifiedare unaffected by the receiver.operation of rendezvous servers. The RVS MUSTSHOULD 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 The SIGNATURE and HMAC verification MUST NOT cover any FROM and RVS_HMAC parameters added by rendezvous servers. Hence, HMAC and SIGNATURE are unaffected by the modifications performed by an RVS. The computation and verification of HMAC and SIGNATURE MUST only coverfollowing sections describe extensions to the originalHIP header withregistration protocol [I-D.koponen-hip-registration], allowing a checksum field setHIP node to zero, MUST NOT cover the pseudo header that contains modified IP addresses, and mUST NOT cover any 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 the HIP registration protocol , allowing a HIP node to register with a rendezvous server for rendezvous service and notifyregister 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 protocol [I-D.ietf-hip-base] itself, allowing establishment of HIP associations via one or more HIP rendezvous server(s). 4.1 LOCATOR Parameter A HIP responder contacted via an RVS MAY use a LOCATOR parameter in the R1 packet to notify the initiator of its current IP address, in conformance with the guidelines specified in . 4.2RENDEZVOUS Registration Type This specification defines an additional registration for the HIP registration protocol [I-D.koponen-hip-registration] that allows registering with a rendezvous server for rendezvous service. Number Registration Type ------ ----------------- 1 RENDEZVOUS 4.3 New4.2 Parameter Formats and Processing 22.214.171.124.1 RVS_HMAC Parameter The RVS_HMAC is an OPTIONALa non-critical parameter whose only difference with the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC): Type [ TBD by IANA (65472(65500 = 2^16 - 2^6)2^5 - 2^2) ] Length 20 HMAC 160 low order bits of a HMAC keyed with the appropriate HIP integrity key (HIP_lg or HIP_gl), established when rendezvous registration happened. This HMAC is computed over the HIP packet, excluding RVS_HMAC and any following parameters. 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 SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity key.key established while registration occurred. 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. 126.96.36.199.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 (65470(65498 = 2^16 - 2^62^5 - 2) ] 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. 188.8.131.52.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 (65474(65502 = 2^16 - 2^62^5 + 2) ] 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 aan RVS. 4.44.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 notNOT 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. IfWhen an RVS needs to rewriterewrites the source IP address of an I1 packet due to egress filtering, thenit MUST add a FROM parameter to the I1 that contasinscontains the initiator's source IP address. This FROM parameter MUST be protected by aan RVS_HMAC keyed with the integrity key established at rendezvous registration. 184.108.40.206 Processing Incoming I1 packets When a rendezvous server receives an I1 whose destination HIT is not its own, it MUST consultconsults its registration database to find a registration for the rendezvous service established by the HIT owner. If it finds an appropriate registration, it MUST relayrelays the packet to the registered IP address. If it does not find an appropriate registration, is MUST dropit 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. 5. Security Considerations The security aspects4.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 differentthe traversed RVS's. 4.3.4 Processing Incoming R1 packets The HIP rendezvous mechanismsbase specification [I-D.ietf-hip-base] 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., it 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 currently being investigated.also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter. 5. Security Considerations This section describesdiscusses the known threats introduced by these HIP extensions and implications on the overall security of HIP and IP.HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to the Internet infrastructure.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 HIP's SIGMA protocol.the HIP base exchange. If an initiator has a priori knowledge of the responder's host identity when it first contacts it via an RVS, it has a means to verify the signatures in the HIP base exchange, thus conforming to the SIGMA protocolwhich is known to be thus resilient to man-in-the-middle attacks. If an initiator does not have a priori knowledge of the responder's host identiyidentity (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 which is equivalent to what exists in the Internet today. However, for reasons of simplicity, this specification does not allow to establish a HIP association via a rendezvous server in an opportunistic manner. 6. IANA Considerations This section is to be interpreted according to .[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.3:4.2: o RVS_HMAC (defined in Section 4.3.1)4.2.1) o FROM (defined in Section 4.3.2)4.2.2) o VIA_RVS (defined in Section 4.3.3)4.2.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 and Juergen Quittek. Julien Laganier and Lars Eggert isare partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework 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 [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [I-D.ietf-hip-dns] Nikander, P. and J. Laganier, "Host Identity Protocol Architecture", draft-ietf-hip-arch-02(HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01 (work in progress), JanuaryFebruary 2005. [I-D.koponen-hip-registration] Koponen, T. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", draft-koponen-hip-registration-00 (work in progress), February 2005. [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. 8.2 Informative References [I-D.ietf-hip-arch] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), FebruaryJanuary 2005. [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-ietf-hip-mm-01 (work in progress), February 2005.  Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.  Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 8.2 Informative References [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993.  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.  Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.  Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01 (work in progress), February 2005. [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. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3013] 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 DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: email@example.com URI: http://www.docomolab-euro.com/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: firstname.lastname@example.org URI: http://www.netlab.nec.de/ Appendix A. Document Revision History +-----------+-------------------------------------------------------+ | Revision | Comments | +-----------+-------------------------------------------------------+ | 03 | Removed architectural discussions. Fixed some | | | requirements keywords. | | 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 email@example.com. 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.