Internet Draft M. Stiemerling Document: draft-stiemerling-hip-nat-02.txt J. Quittek Expires: April 2005 NEC Europe Ltd. October 2004 Problem Statement: HIP operation over Network Address Translators 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 aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo investigates issues for Host Identity Protocol (HIP) nodes that communicate over a network path that includes Network Address Translators (NATs). There are two groups of issues: Operating HIP itself across NATs and operating the IPsec-based data transmission initiated by HIP across NATs. For both groups problems are summarized. Stiemerling, Quittek [Page 1] Internet-Draft HIP and NAT October 2004 Table of Contents 1 Introduction ................................................. 3 2 Terminology .................................................. 3 3 HIP Network Environment ...................................... 4 4 Problems with operating HIP across NATs ...................... 5 4.1 HIP Base Exchange .......................................... 5 4.1.1 HIP over IPv6 ............................................ 6 4.1.2 HIP over IPv4 ............................................ 6 4.2 IPsec Data Exchange ........................................ 7 5 Extensions to HIP ............................................ 7 6 Extension to NATs ............................................ 8 7 HIP unaware NATs ............................................. 8 8 HIP across Twice-NAT ......................................... 9 9 Middleboxes .................................................. 11 9.1 Firewalls .................................................. 11 10 Security Considerations ..................................... 11 11 Acknowledgements ............................................ 12 12 References .................................................. 12 13 Authors' Addresses .......................................... 13 Stiemerling, Quittek [Page 2] Internet-Draft HIP and NAT October 2004 1. Introduction The Host Identity Protocol (HIP) architecture [HIP-ARCH] introduces a new kind of identifier for each host. Instead of using the IP address as host identity, a new Host Identifier is introduced. This additional namespace, separates the host identity from the routing information contained in the IP address. The current version of the HIP Architecture is based on the assumption of full reachability between the IP addresses assigned to the participating hosts. This is usually given if both hosts have IP addresses belonging to the same address realm, for example, if both have public addresses. But if the host's addresses belong to different realms, for example one has a private IP address and the other one a public one, then network address translation must be provided between the realms. So far, network address translation is not integrated into the HIP architecture and HIP [HIP-PROTO] does not have particular means to support it. Problems arising in conjunction with Network Address Translators (NATs) are two-fold. First the HIP base exchange needs to traverse NATs and then the IPsec encoded transport initiated by HIP needs to traverse it (see [RFC2401] for an introduction to IPsec). In general, both protocols have the risk of being blocked by NATs. This document discusses the problems encountered when using HIP in the presence of NATs in Section 4. Impacts on HIP itself and the used IPsec mechanism are elaborated. Section 5 discusses extensions to HIP that potentially can solve some of the problems. Section 6 suggests extensions to the functions provided by today's NATs complementing the HIP extensions. NATs that are not aware of HIP are handled in Section 7 and operating HIP together with twice-NATs is briefly summarized in Section 8. Section 9 gives an outlook an the impact of different other types of middleboxes on HIP. It is not the intend of this memo to promoted the use of NATs in the context of HIP, but since NATs are widely deployed it is necessary to take them into account while developing HIP. 2. Terminology Terms used throughout this document are consistent with IPsec terminology [RFC2401], HIP terminology [HIP-ARCH][HIP-PROTO][HIP-MM], and NAT terminology [RFC2663]. For an introduction to NATs readers are recommended to read [RFC2663]. In this memo the term NAT refers to NAT and NAPT. Twice-NATs are handled separately. Stiemerling, Quittek [Page 3] Internet-Draft HIP and NAT October 2004 3. HIP Network Environment The HIP Architecture described in [HIP-ARCH] assumes full reachability between the IP addresses assigned to the participating hosts. +---------+ -------- +---------+ | HIP | / \ | HIP | | peer |----| Internet |---| peer | | A | \ realm / | B | +---------+ -------- +---------+ Figure 1: Assumed network environment for HIP This is usually given if both hosts have IP addresses belonging to the same address realm, for instance, if both have public addresses or if both have addresses belonging to the same private address realm as shown by Figure 1. Within one realm, IP addresses provide end-to- end routing information between hosts A and B. If A wants to send a packet to B, it is sufficient for A to know the IP address assigned to B. The scenario sketched by Figure 1 is an ideal one. It does not (anymore) match today's current scenarios where an increasing number of hosts use private IP addresses, mainly, because of lack of IP addresses in IPv4. Furthermore, a separation of an organization's network from the public Internet realm hides the organization's network structure and enables more flexible internal renumbering of IP addresses. If the host's addresses belong to different realms, then communication between these hosts requires network address translation between the realms. Network Address Translators (NATs, [RFC2663]) provide this service. Figure 2 shows an example of a host B with a private IP address and a host A with a public IP address. The scenario in Figure 2 is limited to a NAT on peer B's side only, but in general both peers might be located behind NATs. +--+ +---------+ -------- | | -------- +---------+ | HIP | / public \ |N | / private \ | HIP | | peer |--| Internet |--|A |--| Internet |--| peer | | A | \ realm / |T | \ realm / | B | +---------+ -------- | | -------- +---------+ +--+ Figure 2: Network environment with NAT Stiemerling, Quittek [Page 4] Internet-Draft HIP and NAT October 2004 The translation performed by NATs affects the IP header and (in most existing cases) also the transport header. IP addresses and transport port numbers are translated between the address realms. In the scenario illustrated by Figure 2, host A would address all HIP messages that it intends to send to host B to a public IP address that is provided by the NAT. The NAT receives the message for this address (typically in combination with a dynamically chosen port number) and replaces the destination IP address (and typically also the TCP or UPD port number) before it forwards the packet into the private realm. The public IP address (and port number) that the NAT uses for this translation service is in general not known to host A. Therefore, applications that carry address information in their payload or applications that rely on static protocol header fields experience severe problems. Often, the application-level signaling can traverse NATs, but subsequent data exchange fails (see [NATP2P]). NATs are heavily used in IPv4 networks when there is a significant lack of address space. Initially, they were expected not to be present in IPv6 networks, but the authors believe that NATs will also be used in IPv6 networks, despite the availability of a much larger address space. Today, even organizations owning a sufficiently large IPv4 address space tend to use private Internet realms, because this hides their internal network structure and allows to renumber the internal network addresses without communicating this to the public network. 4. Problems with operating HIP across NATs HIP operation can be divided into two phases. The first one is the HIP base exchange using HIP only. The second one is the actual application data exchange via IPsec. This section separately describes the problems that occur in each of the phases when network address translation is integrated into the HIP architecture. 4.1. HIP Base Exchange The HIP base exchange uses different transport mechanisms for IPv6 and IPv4. o IPv6 When IPv6 is used, a HIP-specific IPv6 extension header carries all information necessary (see Section 6 of [HIP-PROTO]). o IPv4 When IPv4 is used, HIP messages are transmitted as UDP payload. (see Appendix E of [HIP-PROTO]). Stiemerling, Quittek [Page 5] Internet-Draft HIP and NAT October 2004 4.1.1. HIP over IPv6 Current implementations use plain IPv6 packets without any payload other than the HIP extension header. This causes problems in combination with NATs that multiplex many private IP addresses into a few public addresses. Usually, this kind of multiplexing is performed on a combination of IP address and TCP or UDP port number. In the absence of a TCP or UDP transport header, typical network address and port translation will fail. Currently there is no specific scheme defined for translating IPv6 HIP extension headers in the absence of TCP or UDP headers. This all is a minor concern right now, since the likelihood of NATs in IPv6 is small. Another problem (that also applies to IPv4) is that HIP provides no explicit means for transmitting the IP address used by a host other than using the source IP address of the packet carrying HIP messages. Even if a host B in Figure 2 would know the public IP address used by the NAT for translation, it has no means of providing this information to host A. 4.1.2. HIP over IPv4 The use of UDP encapsulation for IPv4 transmission enables the HIP base exchange to traverse NATs and to reach their final destination. This encapsulation scheme replaces the IPv6 extension header with a UDP header followed by a HIP header. All HITs and HIP parameters are appended to this new HIP UDP header. UDP transport suffers from many well known problems when traversing NATs (compare Section 2.2 of [RFC3715] also for some issues on UDP traversal). One problem is that often NATs are not able or do not allow to traverse UDP packets, they are blocked and discarded. If NATs do allow UDP packets to traverse, it is not determinable which UDP port number and IP address is used for outgoing UDP packets. HIP over UDP is mandating a fixed port number of 272 for source and destination ports. NATs may change the source port number to any possible port number, for instance, a source port of 272 may be changed by the NAT to 34657. The above paragraph implies that outgoing packets (packets origin in a private address realm and traversing towards the public address realm) are allowed to traverse, but for the opposite way, incoming packets, this is not necessary given. Only incoming packets that are replies to outgoing packets are able to traverse the NAT. For incoming packets, from flows originating in the public address realm, there is no way of traversing. The destination address in the private address realm (more precise the IP address NAT binding) is not given, thus no address mapping is possible. So transmissions originating in the public Internet are unable to traverse (or even reach the NAT), unless the NAT has some pre-configured configurations. Stiemerling, Quittek [Page 6] Internet-Draft HIP and NAT October 2004 4.2. IPsec Data Exchange IPsec secures data transmission between two HIP nodes after their base exchange is completed. Well-known issues with IPsec and NAT are listed in [RFC3715] and apply to the IPsec use of HIP as well. Those issues are separated into NAT intrinsic issues, NAT implementation issues and helper incompatibilities. The NAT intrinsic issues related to IPsec (IKE issues are omitted) are: 1. By using ESP all upper layer headers are invisible to the NAT. So changes of the IP header during NAT traversal invalidate any upper layer checksums that are protected within ESP after ESP decryption. HIP takes care about not invalidating upper layer checksums, by using HITs instead of IP addresses for checksum calculations (see Section 3.5 of [HIP-PROTO]). So this is not applicable here. 2. It is possible to use ESP encrypted packets through a NAT, but as [RFC3715] remarks, the used SPI values have only one-way significance. Furthermore, SPI values may collide at the NAT, meaning that two different peers behind the NAT are using the same SPI value. 3 SPI could be use for multiplexing different IPsec flows at the NAT. But since SPI have only this one-way significance, NATs can only learn the SPI value of outgoing ESP flows, but not the SPI value of the response ESP flow. A possible way of carrying IPsec traffic through NATs has been proposed in [IPSEC-UDP]. IPsec traffic is encapsulated in UDP packets. 5. Extensions to HIP [HIP-MM][HIP-PA] propose new extensions to HIP to make it usable for end host mobility and multi-homing. Out of those proposals, one extension to HIP can be used for HIP and NAT traversal: HIP peers are able to notify other HIP peers about new addresses they have obtained with the REA packet exchange (see Section 4 of [HIP-MM]). With REA a HIP node can notify other HIP nodes about new addresses, for example, about its new address at a NAT. This functionality has been already described and can be used for NAT traversal. The issue is how to determine the publicly reachable IP address, so that it can be announced within the REA packet to the HIP peer. Stiemerling, Quittek [Page 7] Internet-Draft HIP and NAT October 2004 6. Extension to NATs As described in Section 4.2, IPsec SPIs have only one-way significance, meaning that NATs can learn SPI values of outgoing packets, but they cannot learn the corresponding SPI values of incoming packets. Therefore, a matching between SPI values used for outgoing flows to SPI values used for incoming flows is not possible. NATs must learn the corresponding SPI values for outgoing and incoming IPsec flows. There are two ways in doing so. First, NATs can monitor the HIP base exchange and learn the SPI values agreed by both HIP peers. Afterwards, NATs can remember these values and map outgoing and incoming IPsec flows accordingly. Second, HIP peers can use a NAT signaling protocol and signal the appropriate SPI values with IP addresses. NATs can so learn the SPI values out of the signaling protocol. Both approaches require changes to NATs. The first approach would require changes that are only benificial to HIP, the second one would be beneficial for other protocols as well. Possible solutions for signaling NATs SPI values are NSIS NAT/FW traversal [NSIS-NATFW] and MIDCOM. Using MIDCOM in the context of HIP would require some additional knowledge about network topology, for instance, in multihomed environments with different border NATS, host must know which of the multiple NATs to signal for. Therefore, this solution is hard to deploy. By using the NSIS NAT/FW traversal (NATFW NSLP) mechanism HIP nodes could signal the later on used SPI values for both directions. NATFW NSLP always ensures that signaling messages will reach an appropriate NAT and those messages follow exactly the data path (path-coupled signaling). NSIS requires usually both ends, i.e., both HIP peers, to support this new signaling protocol. However, NATFW NSLP offers support for only one end supporting this protocol. HIP peers behind a NATFW NSLP enabled NAT could so configure the local NATs without impacting other networks. An add-on is given through NATFW traversal, too, since on-path firewalls are configured as well. 7. HIP unaware NATs The solutions outlined in Section 6 require that NATs are updated to support new functions, such as HIP itself or NSIS NATFW signaling. By today's measures, NATs are widely deployed and are currently getting a push through low-cost devices rolled-out to broadband connection users, for instance, DSL lines. NATs are deployed in various places, enterprise borders, mobile phone networks offering Stiemerling, Quittek [Page 8] Internet-Draft HIP and NAT October 2004 IP-based services, and many more. Since there many NATs deployed, it will be impossible to upgrade or replace all of them to support HIP or HIP-related extensions. It is the intent of this section to explore how HIP works even in the presence of these HIP unaware NATs. Deployed NATs are currently IPv4 only, so that this section takes them into account only. For HIP over IPv4, UDP encapsulated HIP messages solve already some problems in traversing NATs. Usually, UDP packets can traverse NATs from inside (private Network) to outside (public network) and vice versa when they have been initiated from inside. The other way around, initiated from outside, will be blocked or impossible since the destination IP address of the NAT is not known a priory. In the case that UDP encapsulation works fine for the HIP message exchange, IPsec is still troublesome (see [RFC3715]). Some NAT implementations offer some sort of so-called VPN passthrough, where the NAT learns about IPsec flows and tries to correlate outgoing and incoming SPI values (see [AIREXT] for an example). This works probably only for a small numbers of nodes behind a single NAT, until there will be SPI collisions. The solution for running IPsec through NATs is documented in [IPSEC- UDP] and applicable here, too. HIP should support IPsec over UDP transport through an extension to the signaling. This extension would indicate when to use IPsec over UDP, instead of plain IPsec. 8. HIP across Twice-NAT A type of Network Address Translation is not mentioned in previous sections about traditional NAT and NAPT. These so-called twice-NATs (see [RFC2663]) are translating source and destination address at once while a datagram is translated from one address realm into another. Typically, twice-NATs are used when two private address realms have address collisions, for example, if two enterprises merge their networks and both of them are using the same address realm. Twice-NATs are used for IPv4 networks, but some networks use NAT with protocol translation (NAT-PT, [RFC2766]). These NAT-PT translate from IPv6 to IPV4 and vice versa. This form of NAT is not considered within this memo, since HIP facilitates its own IPv4 to IPv6 mechanism. Figure 3 sketches a scenario where HIP peers A and C are in overlapping address realms, due to address conflicts and HIP peer B is in the public Internet. Stiemerling, Quittek [Page 9] Internet-Draft HIP and NAT October 2004 +--+ +---------+ -------- | | -------- +---------+ | HIP | / private \ |T | / public \ | HIP | | peer |--| Internet |--|W |--| Internet |--| peer | | A | \ realm1 / |I | \ realm / | B | +---------+ -------- |C | -------- +---------+ |E | +---------+ -------- | | | HIP | / private \ |N | | peer |--| Internet |--|A | | C | \ realm2 / |T | +---------+ -------- | | +--+ Figure 3: Network Environment with twice-NAT Twice-NATs are usually operated with application level support, such as DNS proxies or SIP proxies. These proxies intercept application signaling and configure the twice-NAT box according the request. Configuring means allocating the first IP address in one address realm (e.g., realm1) and a second IP address in another address realm (e.g., reaml2). The configuration assures that data from the private realm is sent to one of the twice-NAT's addresses and afterwards mapped^into the other address realm. Furthermore, the proxies will modify the application signaling to reflect the address changes. HIP peer A would see data from HIP peer C actually coming from the twice- NAT's address in realm1. HIP^peer C would see data coming from HIP peer A coming from the twice-NAT's address in realm2. For HIP peer B data from peer A and B would come from one of the public IP addresses of the twice-NAT. For further studies it is assumed that the twice- NAT is running a n:m translation with n=m and n(realm1)=n(realm2), where n is the number of internal IP addresses in each realm and m the number of public IP addresses. It should be noted that traffic either from peer A or C to peer B does not necessarily be traversed through twice-NAT; traditional NAT or NAPT is sufficient. While using DNS queries to find another peer's IP address behind the same twice-NAT, the DNS proxy is configuring the NAT to forward traffic between both peers (peer A and peer C in Figure 3). The HIP base exchange and IPSec traffic should be able to traverse the twice- NAT without any problem since only the address translation is done, but it should be considered that both source and destination address will be changed. There is port mapping, since the address translation is 1:1 and the multiplexing is done on an IP address base. The IPSec traffic is valid for processing at both peers as long as ESP is used only, but the use of AH will result in broken checks, since the IP addresses were changed. Stiemerling, Quittek [Page 10] Internet-Draft HIP and NAT October 2004 The advent of non-DNS based lookup mechanisms (such as described in [RRPROP]) is challenging for HIP with twice-NATs. Either a new type of proxy for this lookup mechanism must be installed at every twice- NAT device or as mentioned in Section 6 a new signaling protocol between HIP peer and twice-NAT can be used. 9. Middleboxes This memo currently investigates the impact of NAT on HIP only. But NATs are belonging to the class of middleboxes, where a middlebox is according to [RFC3234] "any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host." The intention of this section is to allude on the variety of middleboxes that HIP might expect in the Internet. The list of possible middleboxes can be found in [RFC3234]. Future versions of this memo will elaborate the impact of each middlebox type on HIP. Currently, the impact of firewalls is listed here as an example. 9.1. Firewalls It is assumed that HIP peer A and peer B in Figure 2 are located within the same address realm and only separated by an IP firewall middlebox. IP firewalls, usually as known as packet filter firewalls, do inspection on a packet base and decided whether to forward or discard a packet. This type of middlebox is first of all not an obstacle for HIP, as long as the policy rule set defining the filtering allows the HIP base exchange and IPsec traffic to traverse. However, it is common to block traffic with unknown IPv6 extension headers, such as HIP is using, therefore preventing to exchange the HIP base exchange messages. Furthermore, outbound traffic initiated in the protected part is allowed to traverse and corresponding inbound traffic too. On the other hand, traffic initiated from outside and headed inbound is blocked by default. This issue is a problem for the IPsec traffic, since the correlation between outbound IPsec (defined through IP source, IP destination, outbound SPI value) and inbound (defined through IP source, IP destination, inbound SPI value) is impossible to learn for the IP firewall. No correlation is possible, as long as the firewall is unable to learn these corresponding outbound and inbound SPI values. 10. Security Considerations To be done. Stiemerling, Quittek [Page 11] Internet-Draft HIP and NAT October 2004 11. Acknowledgements The authors like to thank Lars Eggert for his valuable comments. 12. References [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [IPSEC-UDP] Huttunen, A., et al, "UDP Encapsulation of IPsec Packets ", draft-ietf-ipsec-udp-encaps-09.txt, Internet Draft ( work in progress), May 2004. [RFC3715] Aboba, B., and W. Dixon, "IPsec-NAT Compatibility Requirements ", RFC 3715, March 2004. [HIP-ARCH] Moskowitz, R., and P. Nikander, "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-06.txt, Internet Draft (work in progress), June 2004. [HIP-PROTO] Moskowitz, R., Nikander, P., and T. Henderson, "Host Identity Protocol", draft-moskowitz-hip-09.txt, Internet Draft (work in progress), February 2004. [HIP-MM] Nikander, P., and P. Jokela, "End-Host Mobility and Multi- Homing with Host Identity Protocol", draft-nikander-hip- mm02.txt, Internet Draft (work in progress), July 2004. [HIP-PA] Nikander, P., Ylitalo, J., and J. Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP way", NDSS 2003, 2003. [NATP2P] Ford, B., Srisuresh, P., and D. Kegel, *(lqPeer-to-Peer (P2P) communication across middleboxes*(rq, draft-ford- midcom-p2p-03.txt, Internet Draft (work in progress), June 2004 [RFC2663] Srisuresh, P., and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999 Stiemerling, Quittek [Page 12] Internet-Draft HIP and NAT October 2004 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1980 [RF3234] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002 [RFC2766] Tsirtsis, G., and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000 [NSIS-NATFW] Stiemerling, M., Tschofenig, H., Martin, M., and C. Aoun, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft- ietf-nsis-nslp-natfw-03.txt, Internet Draft (work in progress), July 2004 [RRPROB] Eggert, L, and J. Laganier, "HIP Resolution and Rendezvous Problem Description", Internet draft, draft-eggert-hiprg-rr-prob- desc-00.txt, (work in progress), October 2004 [AIREXT] Apple Airport stations with VPN passthrough support, http://www.apple.com/airportexpress/specs.html, July 2004, 13. Authors' Addresses Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@netlab.nec.de Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de Intellectual Property Statement Stiemerling, Quittek [Page 13] Internet-Draft HIP and NAT October 2004 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Stiemerling, Quittek [Page 14] Internet-Draft HIP and NAT October 2004