doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5338.txt b/doc/rfc/rfc5338.txt
new file mode 100644
index 0000000..5c4a0f5
--- /dev/null
+++ b/doc/rfc/rfc5338.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                       T. Henderson
+Request for Comments: 5338                            The Boeing Company
+Category: Informational                                      P. Nikander
+                                            Ericsson Research NomadicLab
+                                                                 M. Komu
+                           Helsinki Institute for Information Technology
+                                                          September 2008
+
+
+       Using the Host Identity Protocol with Legacy Applications
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document is an informative overview of how legacy applications
+   can be made to work with the Host Identity Protocol (HIP).  HIP
+   proposes to add a cryptographic name space for network stack names.
+   From an application viewpoint, HIP-enabled systems support a new
+   address family of host identifiers, but it may be a long time until
+   such HIP-aware applications are widely deployed even if host systems
+   are upgraded.  This informational document discusses implementation
+   and Application Programming Interface (API) issues relating to using
+   HIP in situations in which the system is HIP-aware but the
+   applications are not, and is intended to aid implementors and early
+   adopters in thinking about and locally solving systems issues
+   regarding the incremental deployment of HIP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Informational                      [Page 1]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Enabling HIP Transparently within the System ....................4
+      3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
+      3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
+      3.3. Discussion .................................................7
+   4. Users Invoking HIP with a Legacy Application ....................8
+      4.1. Connecting to a HIT or LSI .................................8
+      4.2. Using a Modified DNS Name ..................................9
+      4.3. Other Techniques ...........................................9
+   5. Local Address Management ........................................9
+   6. Security Considerations ........................................11
+   7. Acknowledgments ................................................12
+   8. Informative References .........................................12
+
+1.  Introduction
+
+   The Host Identity Protocol (HIP) [RFC5201] is an experimental effort
+   in the IETF and IRTF to study a new public-key-based name space for
+   use as host identifiers in Internet protocols.  Fully deployed, the
+   HIP architecture would permit applications and users to explicitly
+   request the system to send packets to another host by expressing a
+   location-independent unique name of a peer host when the system call
+   to connect or send packets is performed.  However, there will be a
+   transition period during which systems become HIP-enabled but
+   applications are not.  This informational document does not propose
+   normative specification or even suggest that different HIP
+   implementations use more uniform methods for legacy application
+   support, but is intended instead to aid implementors and early
+   adopters in thinking about and solving systems issues regarding the
+   incremental deployment of HIP.
+
+   When applications and systems are both HIP-aware, the coordination
+   between the application and the system can be straightforward.  For
+   example, using the terminology of the widely used sockets Application
+   Programming Interface (API), the application can issue a system call
+   to send packets to another host by naming it explicitly, and the
+   system can perform the necessary name-to-address mapping to assign
+   appropriate routable addresses to the packets.  To enable this, a new
+   address family for hosts could be defined, and additional API
+   extensions could be defined (such as allowing IP addresses to be
+   passed in the system call, along with the host name, as hints of
+   where to initially try to reach the host).
+
+
+
+
+
+
+Henderson, et al.            Informational                      [Page 2]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   This document does not define a native HIP API such as described
+   above.  Rather, this document is concerned with the scenario in which
+   the application is not HIP-aware and a traditional IP-address-based
+   API is used by the application.
+
+   The discussion so far assumes that applications are written directly
+   to a sockets API.  However, many applications are built on top of
+   middleware that exports a higher-level API to the application.  In
+   this case, for the purpose of this document, we refer to the
+   combination of the middleware and the middleware-based application as
+   an overall application, or client of the sockets API.
+
+   When HIP is enabled on a system, but the applications are not HIP-
+   aware, there are a few basic possibilities to use HIP, each of which
+   may or may not be supported by a given HIP implementation.  We report
+   here on techniques that have been used or considered by experimental
+   HIP implementations.  We organize the discussion around the policy
+   chosen to use or expose HIP to the applications.  The first option is
+   that users are completely unaware of HIP, or are unable to control
+   whether or not HIP is invoked, but rather the system chooses to
+   enable HIP for some or all sessions based on policy.  The second
+   option is that the user makes a decision to try to use HIP by
+   conveying this information somehow within the constraints of the
+   unmodified application.  We discuss both of these use cases in detail
+   below.
+
+   HIP was designed to work with unmodified applications, to ease
+   incremental deployment.  For instance, the HIT is the same size as
+   the IPv6 address, and the design thinking was that, during initial
+   experiments and transition periods, the HITs could substitute in data
+   structures where IPv6 addresses were expected.  However, to a varying
+   degree depending on the mechanism employed, such use of HIP can alter
+   the semantics of what is considered to be an IP address by
+   applications.  Applications use IP addresses as short-lived local
+   handles, long-lived application associations, callbacks, referrals,
+   and identity comparisons [APP-REF].  The transition techniques
+   described below have implications on these different uses of IP
+   addresses by legacy applications, and we will try to clarify these
+   implications in the below discussions.
+
+2.  Terminology
+
+   Callback:   The application at one end retrieves the IP address of
+      the peer and uses that to later communicate "back" to the peer.
+      An example is the FTP PORT command.
+
+   Host Identity:  An abstract concept applied to a computing platform.
+
+
+
+
+Henderson, et al.            Informational                      [Page 3]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   Host Identifier (HI):  A public key of an asymmetric key pair used as
+      a name for a Host Identity.  More details are available in
+      [RFC5201].
+
+   Host Identity Tag (HIT):  A 128-bit quantity composed with the hash
+      of a Host Identity.  More details are available in [RFC4843] and
+      [RFC5201].
+
+   Local Scope Identifier (LSI):  A 32- or 128-bit quantity locally
+      representing the Host Identity at the IPv4 or IPv6 API.
+
+   Long-lived application associations:  The IP address is retained by
+      the application for several instances of communication.
+
+   Referral:   In an application with more than two parties, party B
+      takes the IP address of party A and passes that to party C.  After
+      this, party C uses the IP address to communicate with A.
+
+   Resolver:  The system function used by applications to resolve domain
+      names to IP addresses.
+
+   Short-lived local handle:  The IP addresses is never retained by the
+      application.  The only usage is for the application to pass it
+      from the DNS APIs (e.g., getaddrinfo()) and the API to the
+      protocol stack (e.g., connect() or sendto()).
+
+3.  Enabling HIP Transparently within the System
+
+   When both users and applications are unaware of HIP, but the host
+   administrator chooses to use HIP between hosts, a few options are
+   possible.  The first basic option is to perform a mapping of the
+   application-provided IP address to a host identifier within the
+   stack.  The second option, if DNS is used, is to interpose a local
+   agent in the DNS resolution process and to return to the application
+   a HIT or a locally scoped handle, formatted like an IP address.
+
+3.1.  Applying HIP to Cases in Which IP Addresses Are Used
+
+   Consider the case in which an application issues a "connect(ip)"
+   system call to set the default destination to a system named by
+   address "ip", but for which the host administrator would like to
+   enable HIP to protect the communications.  The user or application
+   intends for the system to communicate with the host reachable at that
+   IP address.  The decision to invoke HIP must be done on the basis of
+   host policy.  For example, when an IPsec-based implementation of HIP
+   is being used, a policy may be entered into the security policy
+   database that mandates to use or to try HIP based on a match on the
+   source or destination IP address, port numbers, or other factors.
+
+
+
+Henderson, et al.            Informational                      [Page 4]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   The mapping of IP address to host identifier may be implemented by
+   modifying the host operating system or by wrapping the existing
+   sockets API, such as in the TESLA approach [TESLA].
+
+   There are a number of ways that HIP could be configured by the host
+   administrator in such a scenario.
+
+   Manual configuration:
+
+      Pre-existing Security Associations (SAs) may be available due to
+      previous administrative action, or a binding between an IP address
+      and a HIT could be stored in a configuration file or database.
+
+   Opportunistically:
+
+      The system could send an I1 to the Responder with an empty value
+      for Responder HIT.
+
+   Using DNS to map IP addresses to HIs:
+
+      If the Responder has host identifiers registered in the forward
+      DNS zone and has a PTR record in the reverse zone, the Initiator
+      could perform a reverse+forward lookup to learn the HIT associated
+      with the address.  Although the approach should work under normal
+      circumstances, it has not been tested to verify that there are no
+      recursion or bootstrapping issues, particularly if HIP is used to
+      secure the connection to the DNS servers.  Discussion of the
+      security implications of the use or absence of DNS Security
+      (DNSSEC) is deferred to the Security Considerations section.
+
+   Using HIP in the above fashion can cause additional setup delays
+   compared to using plain IP.  For opportunistic mode, a host must wait
+   to learn whether the peer is HIP-capable, although the delays may be
+   mitigated in some implementations by sending initial packets (e.g.,
+   TCP SYN) in parallel to the HIP I1 packet and waiting some time to
+   receive a HIP R1 before processing a TCP SYN/ACK.  Note that there
+   presently does not exist specification for how to invoke such
+   connections in parallel.  Resolution latencies may also be incurred
+   when using DNS in the above fashion.
+
+   A possible way to reduce the above-noted latencies, in the case that
+   the application uses DNS, would be for the system to
+   opportunistically query for HIP records in parallel to other DNS
+   resource records, and to temporarily cache the HITs returned with a
+   DNS lookup, indexed by the IP addresses returned in the same entry,
+   and pass the IP addresses up to the application as usual.  If an
+   application connects to one of those IP addresses within a short time
+   after the lookup, the host should initiate a base exchange using the
+
+
+
+Henderson, et al.            Informational                      [Page 5]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   cached HITs.  The benefit is that this removes the uncertainty/delay
+   associated with opportunistic HIP, because the DNS record suggests
+   that the peer is HIP-capable.
+
+3.2.  Interposing a HIP-Aware Agent in the DNS Resolution
+
+   In the previous section, it was noted that a HIP-unaware application
+   might typically use the DNS to fetch IP addresses prior to invoking
+   socket calls.  A HIP-enabled system might make use of DNS to
+   transparently fetch host identifiers for such domain names prior to
+   the onset of communication.
+
+   A system with a local DNS agent could alternately return a Local
+   Scope Identifier (LSI) or HIT rather than an IP address, if HIP
+   information is available in the DNS or other directory that binds a
+   particular domain name to a host identifier, and otherwise to return
+   an IP address as usual.  The system can then maintain a mapping
+   between LSI and host identifier and perform the appropriate
+   conversion at the system call interface or below.  The application
+   uses the LSI or HIT as it would an IP address.  This technique has
+   been used in overlay networking experiments such as the Internet
+   Indirection Infrastructure (i3) and by at least one HIP
+   implementation.
+
+   In the case when resolvers can return multiple destination
+   identifiers for an application, it may be configured that some of the
+   identifiers can be HIP-based identifiers, and the rest can be IPv4 or
+   IPv6 addresses.  The system resolver may return HIP-based identifiers
+   in front of the list of identifiers when the underlying system and
+   policies support HIP.  An application processing the identifiers
+   sequentially will then first try a HIP-based connection and only then
+   other non-HIP based connections.  However, certain applications may
+   launch the connections in parallel.  In such a case, the non-HIP
+   connections may succeed before HIP connections.  Based on local
+   system policies, a system may disallow such behavior and return only
+   HIP-based identifiers when they are found from DNS.
+
+   If the application obtains LSIs or HITs that it treats as IP
+   addresses, a few potential hazards arise.  First, applications that
+   perform referrals may pass the LSI to another system that has no
+   system context to resolve the LSI back to a host identifier or an IP
+   address.  Note that these are the same type of applications that will
+   likely break if used over certain types of network address
+   translators (NATs).  Second, applications may cache the results of
+   DNS queries for a long time, and it may be hard for a HIP system to
+   determine when to perform garbage collection on the LSI bindings.
+   However, when using HITs, the security of using the HITs for identity
+   comparison may be stronger than in the case of using IP addresses.
+
+
+
+Henderson, et al.            Informational                      [Page 6]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   Finally, applications may generate log files, and administrators or
+   other consumers of these log files may become confused to find LSIs
+   or HITs instead of IP addresses.  Therefore, it is recommended that
+   the HIP software logs the HITs, LSIs (if applicable), corresponding
+   IP addresses, and Fully Qualified Domain Name (FQDN)-related
+   information so that administrators can correlate other logs with HIP
+   identifiers.
+
+   It may be possible for an LSI or HIT to be routable or resolvable,
+   either directly or through an overlay, in which case it would be
+   preferable for applications to handle such names instead of IP
+   addresses.  However, such networks are out of scope of this document.
+
+3.3.  Discussion
+
+   Solutions preserving the use of IP addresses in the applications have
+   the benefit of better support for applications that use IP addresses
+   for long-lived application associations, callbacks, and referrals,
+   although it should be noted that applications are discouraged from
+   using IP addresses in this manner due to the frequent presence of
+   NATs [RFC1958].  However, they have weaker security properties than
+   the approaches outlined in Section 3.2 and Section 4, because the
+   binding between host identifier and address is weak and not visible
+   to the application or user.  In fact, the semantics of the
+   application's "connect(ip)" call may be interpreted as "connect me to
+   the system reachable at IP address ip" but perhaps no stronger
+   semantics than that.  HIP can be used in this case to provide perfect
+   forward secrecy and authentication, but not to strongly authenticate
+   the peer at the onset of communications.
+
+   Using IP addresses at the application layer may not provide the full
+   potential benefits of HIP mobility support.  It allows for mobility
+   if the system is able to readdress long-lived, connected sockets upon
+   a HIP readdress event.  However, as in current systems, mobility will
+   break in the connectionless case, when an application caches the IP
+   address and repeatedly calls sendto(), or in the case of TCP when the
+   system later opens additional sockets to the same destination.
+
+   Section 4.1.6 of the base HIP protocol specification [RFC5201] states
+   that implementations that learn of HIT-to-IP address bindings through
+   the use of HIP opportunistic mode must not enforce those bindings on
+   later communications sessions.  This implies that when IP addresses
+   are used by the applications, systems that attempt to
+   opportunistically set up HIP must not assume that later sessions to
+   the same address will communicate with the same host.
+
+
+
+
+
+
+Henderson, et al.            Informational                      [Page 7]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   The legacy application is unaware of HIP and therefore cannot notify
+   the user when the application uses HIP.  However, the operating
+   system can notify the user of the usage of HIP through a user agent.
+   Further, it is possible for the user agent to name the network
+   application that caused a HIP-related event.  This way, the user is
+   aware when he or she is using HIP even though the legacy network
+   application is not.  Based on usability tests from initial
+   deployments, displaying the HITs and LSIs should be avoided in user
+   interfaces.  Instead, traditional security measures (lock pictures,
+   colored address bars) should be used where possible.
+
+   One drawback to spoofing the DNS resolution is that some
+   applications, or selected instances of an application, actually may
+   want to fetch IP addresses (e.g., diagnostic applications such as
+   ping).  One way to provide finer granularity on whether the resolver
+   returns an IP address or an LSI is to have the user form a modified
+   domain name when he or she wants to invoke HIP.  This leads us to
+   consider, in the next section, use cases for which the end user
+   explicitly and selectively chooses to enable HIP.
+
+4.  Users Invoking HIP with a Legacy Application
+
+   The previous section described approaches for configuring HIP for
+   legacy applications that did not necessarily involve the user.
+   However, there may be cases in which a legacy application user wants
+   to use HIP for a given application instance by signaling to the HIP-
+   enabled system in some way.  If the application user interface or
+   configuration file accepts IP addresses, there may be an opportunity
+   to provide a HIT or an LSI in its place.  Furthermore, if the
+   application uses DNS, a user may provide a specially crafted domain
+   name to signal to the resolver to fetch HIP records and to signal to
+   the system to use HIP.  We describe both of these approaches below.
+
+4.1.  Connecting to a HIT or LSI
+
+   Section 3.2 above describes the use of HITs or LSIs as spoofed return
+   values of the DNS resolution process.  A similar approach that is
+   more explicit is to configure the application to connect directly to
+   a HIT (e.g., "connect(HIT)" as a socket call).  This scenario has
+   stronger security semantics, because the application is asking the
+   system to send packets specifically to the named peer system.  HITs
+   have been defined as Overlay Routable Cryptographic Hash Identifiers
+   (ORCHIDs) such that they cannot be confused with routable IP
+   addresses; see [RFC4843].
+
+   This approach also has a few challenges.  Using HITs can be more
+   cumbersome for human users (due to the flat HIT name space) than
+   using either IPv6 addresses or domain names.  Another challenge with
+
+
+
+Henderson, et al.            Informational                      [Page 8]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   this approach is in actually finding the IP addresses to use, based
+   on the HIT.  Some type of HIT resolution service would be needed in
+   this case.  A third challenge of this approach is in supporting
+   callbacks and referrals to possibly non-HIP-aware hosts.  However,
+   since most communications in this case would likely be to other HIP-
+   aware hosts (else the initial HIP associations would fail to
+   establish), the resulting referral problem may be that the peer host
+   supports HIP but is not able to perform HIT resolution for some
+   reason.
+
+4.2.  Using a Modified DNS Name
+
+   Specifically, if the application requests to resolve "HIP-
+   www.example.com" (or some similar prefix string), then the system
+   returns an LSI, while if the application requests to resolve
+   "www.example.com", IP address(es) are returned as usual.  The use of
+   a prefix rather than suffix is recommended, and the use of a string
+   delimiter that is not a dot (".") is also recommended, to reduce the
+   likelihood that such modified DNS names are mistakenly treated as
+   names rooted at a new top-level domain.  Limits of domain name length
+   or label length (255 or 63, respectively) should be considered when
+   prepending any prefixes.
+
+4.3.  Other Techniques
+
+   Alternatives to using a modified DNS name that have been experimented
+   with include the following.  Command-line tools or tools with a
+   graphical user interface (GUI) can be provided by the system to allow
+   a user to set the policy on which applications use HIP.  Another
+   common technique, for dynamically linked applications, is to
+   dynamically link the application to a modified library that wraps the
+   system calls and interposes HIP layer communications on them; this
+   can be invoked by the user by running commands through a special
+   shell, for example.
+
+5.  Local Address Management
+
+   The previous two sections focused mainly on controlling client
+   behavior (HIP initiator).  We must also consider the behavior for
+   servers.  Typically, a server binds to a wildcard IP address and
+   well-known port.  In the case of HIP use with legacy server
+   implementations, there are again a few options.  The system may be
+   configured manually to always, optionally (depending on the client
+   behavior), or never use HIP with a particular service, as a matter of
+   policy, when the server specifies a wildcard (IP) address.
+
+
+
+
+
+
+Henderson, et al.            Informational                      [Page 9]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   When a system API call such as getaddrinfo [RFC3493] is used for
+   resolving local addresses, it may also return HITs or LSIs, if the
+   system has assigned HITs or LSIs to internal virtual interfaces
+   (common in many HIP implementations).  The application may use such
+   identifiers as addresses in subsequent socket calls.
+
+   Some applications may try to bind a socket to a specific local
+   address, or may implement server-side access control lists based on
+   socket calls such as getsockname() and getpeername() in the C-based
+   socket APIs.  If the local address specified is an IP address, again,
+   the underlying system may be configured to still use HIP.  If the
+   local address specified is a HIT (Section 4), the system should
+   enforce that connections to the local application can only arrive to
+   the specified HIT.  If a system has many HIs, an application that
+   binds to a single HIT cannot accept connections to the other HIs but
+   the one corresponding to the specified HIT.
+
+   When a host has multiple HIs and the socket behavior does not
+   prescribe the use of any particular HI as a local identifier, it is a
+   matter of local policy as to how to select a HI to serve as a local
+   identifier.  However, systems that bind to a wildcard may face
+   problems when multiple HITs or LSIs are defined.  These problems are
+   not specific to HIP per se, but are also encountered in non-HIP
+   multihoming scenarios with applications not designed for multihoming.
+
+   As an example, consider a client application that sends a UDP
+   datagram to a server that is bound to a wildcard.  The server
+   application receives the packet using recvfrom() and sends a response
+   using sendto().  The problem here is that sendto() may actually use a
+   different server HIT than the client assumes.  The client will drop
+   the response packet when the client implements access control on the
+   UDP socket (e.g., using connect()).
+
+   Reimplementing the server application using the sendmsg() and
+   recvmsg() to support multihoming (particularly considering the
+   ancillary data) would be the ultimate solution to this problem, but
+   with legacy applications is not an option.  As a workaround, we make
+   suggestion for servers providing UDP-based services with non-
+   multihoming-capable services.  Such servers should announce only the
+   HIT or public key that matches to the default outgoing HIT of the
+   host to avoid such problems.
+
+   Finally, some applications may create a connection to a local HIT.
+   In such a case, the local system may use NULL encryption to avoid
+   unnecessary encryption overhead, and may be otherwise more permissive
+   than usual such as excluding authentication, Diffie-Hellman exchange,
+   and puzzle.
+
+
+
+
+Henderson, et al.            Informational                     [Page 10]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+6.  Security Considerations
+
+   In this section, we discuss the security of the system in general
+   terms, outlining some of the security properties.  However, this
+   section is not intended to provide a complete risk analysis.  Such an
+   analysis would, in any case, be dependent on the actual application
+   using HIP, and is therefore considered out of scope.
+
+   The scenarios outlined above differ considerably in their security
+   properties.  When the DNS is used, there are further differences
+   related to whether or not DNSSEC [RFC4033] is used, and whether the
+   DNS zones are considered trustworthy enough.  Here we mean that there
+   should exist a delegation chain to whatever trust anchors are
+   available in the respective trees, and the DNS zone administrators in
+   charge of the netblock should be trusted to put in the right
+   information.
+
+   When IP addresses are used by applications to name the peer system,
+   the security properties depend on the configuration method.  With
+   manual configuration, the security of the system is comparable to a
+   non-HIP system with similar IPsec policies.  The security semantics
+   of an initial opportunistic key exchange are roughly equal to non-
+   secured IP; the exchange is vulnerable to man-in-the-middle attacks.
+   However, the system is less vulnerable to connection hijacking
+   attacks.  If the DNS is used, if both zones are secured (or the HITs
+   are stored in the reverse DNS record) and the client trusts the
+   DNSSEC signatures, the system may provide a fairly high security
+   level.  However, much depends on the details of the implementation,
+   the security and administrative practices used when signing the DNS
+   zones, and other factors.
+
+   Using the forward DNS to map a domain name into an LSI is a case that
+   is closest to the most typical use scenarios today.  If DNSSEC is
+   used, the result is fairly similar to the current use of certificates
+   with Transport Layer Security (TLS).  If DNSSEC is not used, the
+   result is fairly similar to the current use of plain IP, with the
+   additional protection of data integrity, confidentiality, and
+   prevention of connection hijacking that opportunistic HIP provides.
+   If DNSSEC is used, data integrity and data origin authentication
+   services are added to the normal DNS query protocol, thereby
+   providing more certainty that the desired host is being contacted, if
+   the DNS records themselves are trustworthy.
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Informational                     [Page 11]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   If the application is basing its operations on HITs, the connections
+   become automatically secured due to the implicit channel bindings in
+   HIP.  That is, when the application makes a connect(HIT) system call,
+   either the resulting packets will be sent to a node possessing the
+   corresponding private key or the security association will fail to be
+   established.
+
+   When the system provides (spoofs) LSIs or HITs instead of IP
+   addresses as the result of name resolution, the resultant fields may
+   inadvertently show up in user interfaces and system logs, which may
+   cause operational concerns for some network administrators.
+   Therefore, it is recommended that the HIP software logs the HITs,
+   LSIs (if applicable), corresponding IP addresses, and FQDN-related
+   information so that administrators can correlate other logs with HIP
+   identifiers.
+
+7.  Acknowledgments
+
+   Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,
+   Julien Laganier, and Jukka Ylitalo have provided comments on
+   different versions of this document.  The document received
+   substantial and useful comments during the review phase from David
+   Black, Lars Eggert, Peter Koch, Thomas Narten, and Pekka Savola.
+
+8.  Informative References
+
+   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
+
+   [RFC4843]   Nikander, P., Laganier, J., and F. Dupont, "An IPv6
+              Prefix for Overlay Routable Cryptographic Hash Identifiers
+              (ORCHID)", RFC 4843, April 2007.
+
+   [TESLA]     Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA:  A
+              Transparent, Extensible Session-Layer Architecture for
+              End-to-end Network Services",  Proceedings of USENIX
+              Symposium on Internet Technologies and Systems (USITS),
+              pages 211-224, March 2003.
+
+   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
+              Internet", RFC 1958, June 1996.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+
+
+
+
+
+Henderson, et al.            Informational                     [Page 12]
+
+RFC 5338           Using HIP with Legacy Applications     September 2008
+
+
+   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
+              Stevens, "Basic Socket Interface Extensions for IPv6", RFC
+              3493, February 2003.
+
+   [APP_REF]  Nordmark, E., "Shim6 Application Referral Issues", Work in
+              Progress, July 2005.
+
+Authors' Addresses
+
+   Thomas Henderson
+   The Boeing Company
+   P.O. Box 3707
+   Seattle, WA
+   USA
+
+   EMail: thomas.r.henderson@boeing.com
+
+
+   Pekka Nikander
+   Ericsson Research NomadicLab
+   JORVAS  FIN-02420
+   FINLAND
+
+   Phone: +358 9 299 1
+   EMail: pekka.nikander@nomadiclab.com
+
+
+   Miika Komu
+   Helsinki Institute for Information Technology
+   Metsaenneidonkuja 4
+   Helsinki  FIN-02420
+   FINLAND
+
+   Phone: +358503841531
+   EMail: miika@iki.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Informational                     [Page 13]
+
+RFC 5338           Using HIP with Legacy Applications     September 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Informational                     [Page 14]
+