draft-ietf-hip-native-api-06.txt   draft-ietf-hip-native-api-07.txt 
Host Identity Protocol M. Komu Host Identity Protocol M. Komu
Internet-Draft Helsinki Institute for Information Internet-Draft Helsinki Institute for Information
Intended status: Experimental Technology Intended status: Experimental Technology
Expires: November 23, 2009 Henderson Expires: January 14, 2010 Henderson
The Boeing Company The Boeing Company
May 22, 2009 July 13, 2009
Basic Socket Interface Extensions for Host Identity Protocol (HIP) Basic Socket Interface Extensions for Host Identity Protocol (HIP)
draft-ietf-hip-native-api-06 draft-ietf-hip-native-api-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 23, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document defines extensions to the current sockets API for Host This document defines extensions to the current sockets API for the
Identity Protocol (HIP). The extensions focus on the use of public- Host Identity Protocol (HIP). The extensions focus on the use of
key based identifiers discovered via DNS resolution, but define also public-key based identifiers discovered via DNS resolution, but
interfaces for manual bindings between HITs and locators. With the define also interfaces for manual bindings between HITs and locators.
extensions, the application can also support more relaxed security With the extensions, the application can also support more relaxed
models where the communication can be non-HIP based, according to security models where the communication can be non-HIP based,
local policies. The extensions in document are experimental and according to local policies. The extensions in document are
provide basic tools for futher experimentation with policies. experimental and provide basic tools for further experimentation with
policies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. API Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. API Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5 3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5
3.2. Interaction without a Resolver . . . . . . . . . . . . . . 5 3.2. Interaction without a Resolver . . . . . . . . . . . . . . 6
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 7
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 6 4.1. Socket Family and Address Structure Extensions . . . . . . 7
4.1. Socket Family and Address Structure Extensions . . . . . . 6 4.2. Extensions to Resolver Data Structures . . . . . . . . . . 9
4.2. Extensions to Resolver Data Structures . . . . . . . . . . 8 4.3. The Use of getsockname and getpeername Functions . . . . . 11
4.2.1. Resolver Usage . . . . . . . . . . . . . . . . . . . . 9 4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 11
4.3. The Use of getsockname and getpeername Functions . . . . . 10 4.5. Verification of Source HIT Type . . . . . . . . . . . . . 12
4.4. Validating HITs . . . . . . . . . . . . . . . . . . . . . 10
4.5. Source HIT Selection by the System . . . . . . . . . . . . 11
4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 12 4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 12
5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 14 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines C-based sockets Application Programming This document defines C-based sockets Application Programming
Interface (API) extensions for handling HIP-based identifiers Interface (API) extensions for handling HIP-based identifiers
explicitly in HIP-aware applications. It is up to the applications, explicitly in HIP-aware applications. It is up to the applications,
or high-level programming languages or libraries, to manage the or high-level programming languages or libraries, to manage the
identifiers. The extensions in this document are mainly related to identifiers. The extensions in this document are mainly related to
the use case in which a DNS resolution step has occurred prior to the the use case in which a DNS resolution step has occurred prior to the
creation of a new socket, and assumes that the system has cached or creation of a new socket, and assumes that the system has cached or
skipping to change at page 3, line 25 skipping to change at page 3, line 25
The DNS extensions for HIP are described in [RFC5205]. The The DNS extensions for HIP are described in [RFC5205]. The
extensions also cover the case in which an application may want to extensions also cover the case in which an application may want to
explicitly provide suggested locators with the identifiers, including explicitly provide suggested locators with the identifiers, including
supporting the opportunistic case in which the system does not know supporting the opportunistic case in which the system does not know
the peer host identity. the peer host identity.
The Host Identity Protocol (HIP) [RFC4423] proposes a new The Host Identity Protocol (HIP) [RFC4423] proposes a new
cryptographic namespace by separating the roles of end-point cryptographic namespace by separating the roles of end-point
identifiers and locators by introducing a new namespace to the TCP/IP identifiers and locators by introducing a new namespace to the TCP/IP
stack. SHIM6 [I-D.ietf-shim6-proto] is another protocol based on stack. SHIM6 [I-D.ietf-shim6-proto] is another protocol based on
identity-locator split. Note that the APIs specified in this identity-locator split. The APIs specified in this document are
document are specific to HIP. However, the APIs here have been specific to HIP, but have been designed as much as possible so as not
designed as much as possible so as not to preclude its use with other to preclude its use with other protocols. The use of these APIs with
protocols. The use of these APIs with other protocols is, other protocols is, nevertheless, for further study.
nevertheless, for further study.
The APIs in this document are based on IPv6 addresses with the ORCHID
prefix [RFC4843]. ORCHIDs are derived from Host Identifiers using a
hash and fitting the result into an IPv6 address. Such addresses are
called Host Identity Tags (HITs) and they can be distinguished from
other IPv6 addresses with the ORCHID prefix.
Applications can observe the HIP layer and its identifiers in the Applications can observe the HIP layer and its identifiers in the
networking stacks with varying degrees of visibility. [RFC5338] networking stacks with varying degrees of visibility. [RFC5338]
discusses the lowest levels of visibility in which applications are discusses the lowest levels of visibility in which applications are
completely unaware of the underlying HIP layer. Such HIP-unaware completely unaware of the underlying HIP layer. Such HIP-unaware
applications in some circumstances use HIP-based identifiers, such as applications in some circumstances use HIP-based identifiers, such as
LSIs or HITs, instead of IPv4 or IPv6 addresses and cannot observe LSIs or HITs, instead of IPv4 or IPv6 addresses and cannot observe
the identifier-locator bindings. the identifier-locator bindings.
This document specifies extensions to [RFC3493] to define a new This document specifies extensions to [RFC3493] to define a new
socket address family, AF_HIP. The macro AF_HIP is used as an alias socket address family, AF_HIP. Similarly to other address families,
for PF_HIP in this document because the distinction between AF and PF AF_HIP can used as an alias for PF_HIP. The extensions also describe
has been lost in practice. The extensions also describe a new socket a new socket address structure for sockets using HITs explicitly and
address structure for sockets using Host Identity Tags (HITs) describe how the socket calls in [RFC3493] are adapted or extended as
explicitly and describe how the socket calls in [RFC3493] are adapted a result.
or extended as a result.
Some applications may accept incoming communications from any Some applications may accept incoming communications from any
identifier. Other applications may initiate outgoing communications identifier. Other applications may initiate outgoing communications
without the knowledge of the peer identifier in Opportunistic Mode without the knowledge of the peer identifier in Opportunistic Mode
[RFC5201] by just relying on a peer locator. This document describes (section 4.1.6 in [RFC5201]) by just relying on a peer locator. This
how to address both situations using "wildcards" as described later document describes how to address both situations using "wildcards"
in this document. as described later in this document.
There are two related API documents. Multihoming and explicit There are two related API documents. Multihoming and explicit
locator-handling related APIs are defined in locator-handling related APIs are defined in
[I-D.ietf-shim6-multihome-shim-api]. IPsec related policy attributes [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy attributes
and channel bindings APIs are defined in [I-D.ietf-btns-c-api]. Most and channel bindings APIs are defined in [I-D.ietf-btns-c-api]. Most
of the extensions defined in this document can be used independently of the extensions defined in this document can be used independently
of the two mentioned related API documents. of the two mentioned API documents.
The identity-locator split introduced by HIP introduces some policy The identity-locator split introduced by HIP introduces some policy
related challenges with datagram oriented sockets, opportunistic related challenges with datagram oriented sockets, opportunistic
mode, and manual bindings between HITs and locators. The extensions mode, and manual bindings between HITs and locators. The extensions
in this document are of experimental nature and provide basic tools in this document are of an experimental nature and provide basic
for experimenting with policies. Policy related issues are left for tools for experimenting with policies. Policy related issues are
further experimentation. left for further experimentation.
To recap, the extensions in this document have three goals. The To recap, the extensions in this document have three goals. The
first goal is to allow HIP-aware applications to open sockets to first goal is to allow HIP-aware applications to open sockets to
other hosts based on the HITs alone, presuming that the underlying other hosts based on the HITs alone, presuming that the underlying
system can resolve the HITs to addresses used for initial contact. system can resolve the HITs to addresses used for initial contact.
The second goal is that applications can explicitly initiate The second goal is that applications can explicitly initiate
communications with unknown peer identifiers. The third goal is to communications with unknown peer identifiers. The third goal is to
define how HIP-aware applications may provide suggested initial illustrate how HIP-aware applications can use the SHIM API
contact addresses along with the HITs. [I-D.ietf-shim6-multihome-shim-api] to manually map locators to HITs.
2. Terminology 2. Terminology
The terms used in this document are summarized in Table 1. The terms used in this document are summarized in Table 1.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| HIP | Host Identity Protocol | | HIP | Host Identity Protocol |
| HIT | Host Identity Tag, a 100-bit hash of a public key with | | HIT | Host Identity Tag, a 100-bit hash of a public key with |
skipping to change at page 5, line 11 skipping to change at page 5, line 18
the case in which a resolver is involved in name resolution is the case in which a resolver is involved in name resolution is
described, and then the case in which no resolver is involved is described, and then the case in which no resolver is involved is
described. described.
3.1. Interaction with the Resolver 3.1. Interaction with the Resolver
Before an application can establish network communications with the Before an application can establish network communications with the
entity named by a given FQDN or relative host name, the application entity named by a given FQDN or relative host name, the application
must translate the name into the corresponding identifier(s). DNS- must translate the name into the corresponding identifier(s). DNS-
based hostname-to-identifier translation is illustrated in Figure 1. based hostname-to-identifier translation is illustrated in Figure 1.
The application calls the resolver in step a to resolve an FQDN step The application calls the resolver in step (a) to resolve an FQDN to
b. The DNS server responds with a list of HITs and a set of locators HIT(s). The resolver queries the DNS in step (b) to map the FQDN to
step c. Optionally in step d, the resolver caches the HIT to locator a host identifier and locator (A and AAAA records). It should be
mapping to the HIP module. The resolver returns the HITs to the noticed that the FQDN may map to multiple host identifiers and
application step e. Finally, the application selects one HIT and locators, and this step may involve multiple DNS transactions,
uses it in a socket call such as connect() in step f. including queries for A, AAAA, HI and possibly other resource
records. The DNS server responds with a list of HIP resource records
in step (c). Optionally in step (d), the resolver caches the HIT to
locator mapping with the HIP module. The resolver converts the HIP
records to HITs and returns the HITs to the application contained in
HIP socket address structures in step (e). Depending on the
parameters for the resolver call, the resolver may return also other
socket address structures to the application. Finally, the
application receives the socket address structure(s) from the
resolver and uses them in socket calls such as connect() in step (f).
+----------+ +----------+
| | | |
| DNS | | DNS |
| | | |
+----------+ +----------+
^ | ^ |
b. <FQDN> | | c. <HITs+locators b. QNAME=FQDN | | c. HIP and
| v = HITs+locs> | | A/AAAA
| v RR(s)
+-------------+ a. getaddrinfo(<FQDN>) +----------+ +-------------+ a. getaddrinfo(<FQDN>) +----------+
| |------------------------>| | | |------------------------>| |
| Application | | Resolver | | Application | | Resolver |
| |<------------------------| | | |<------------------------| |
+-------------+ e. <HITs> +----------+ +-------------+ e. <HITs> +----------+
| | | |
| | | | d. HIP and
| f. connect(<HIT>) | d. <HITs+locs> | f. connect(<HIT>) | A/AAAA
| or any other socket call | RR(s)
v v v v
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| TCP/IP | | HIP | | TCP/IP | | HIP |
| Stack | | | | Stack | | |
+----------+ +----------+ +----------+ +----------+
Figure 1 Figure 1
In practice, the resolver functionality can be implemented in In practice, the resolver functionality can be implemented in
different ways. For example, it may be implemented in existing different ways. For example, it may be implemented in existing
resolver libraries or as a DNS proxy. resolver libraries or as a HIP-aware interposing agent.
3.2. Interaction without a Resolver 3.2. Interaction without a Resolver
The extensions in this document focus on the use of the resolver to The extensions in this document focus on the use of the resolver to
map host names to HITs and locators in HIP-aware applications. The map host names to HITs and locators in HIP-aware applications. The
resolver associates implicitly the HIT with the locator(s) by e.g. resolver may implicitly associate a HIT with the corresponding
communicating the HIT-to-IP mapping to the HIP daemon. However, it locator(s) by communicating the HIT-to-IP mapping to the HIP daemon.
is possible that an application operates directly on a peer HIT However, it is possible that an application operates directly on a
without interacting with the resolver. In such a case, the peer HIT without interacting with the resolver. In such a case, the
application may resort to the system to map the peer HIT to an IP application may resort to the system to map the peer HIT to an IP
address. Alternatively, the application can explicitly map the HIT address. Alternatively, the application can explicitly map the HIT
to an IP address using socket options as specified in to an IP address using socket options as specified in Section 4.6.
[I-D.ietf-shim6-multihome-shim-api]. Full support for all of the Full support for all of the extensions defined in this draft requires
extensions defined in this draft requires shim socket options to be a number of shim socket options [I-D.ietf-shim6-multihome-shim-api]
implemented by the system. to be implemented by the system.
4. API Syntax and Semantics 4. API Syntax and Semantics
In this section, we describe the native HIP APIs using the syntax of In this section, we describe the native HIP APIs using the syntax of
the C programming language. We limit the description to the the C programming language. We limit the description to the
interfaces and data structures that are either modified or completely interfaces and data structures that are either modified or completely
new, because the native HIP APIs are otherwise identical to the new, because the native HIP APIs are otherwise identical to the
sockets API [POSIX]. sockets API [POSIX].
4.1. Socket Family and Address Structure Extensions 4.1. Socket Family and Address Structure Extensions
skipping to change at page 7, line 4 skipping to change at page 7, line 43
struct sockaddr_hip { struct sockaddr_hip {
sa_family_t ship_family; sa_family_t ship_family;
in_port_t ship_port; in_port_t ship_port;
uint32_t ship_pad; uint32_t ship_pad;
uint64_t ship_flags; uint64_t ship_flags;
hip_hit_t ship_hit; hip_hit_t ship_hit;
uint8_t ship_reserved[16]; uint8_t ship_reserved[16];
}; };
Figure 2 Figure 2
Figure 2 is in in 4.3BSD format. The family of the socket, Figure 2 is in in 4.3BSD format. The family of the socket,
ship_family, is set to AF_HIP. The port number ship_port is two ship_family, is set to AF_HIP. The port number ship_port is two
octets in network byte order. and the ship_hit is 16 octets in octets in network byte order and the ship_hit is 16 octets in network
network byte order. An implementation may have extra member(s) in byte order. An implementation may have extra member(s) in this
this structure. structure.
The application usually sets the ship_hit field using the resolver. The application usually sets the ship_hit field using the resolver.
However, the application can use three special wildcard macros to set However, the application can use three special constants to set a
a value directly into the ship_hit field. The macros are wildcard value manually into the ship_hit field. The constants are
HIP_HIT_ANY, HIP_HIT_ANY_PUB, HIP_HIT_ANY_TMP and HIP_ADDR_ANY. The HIP_HIT_ANY, HIP_HIT_ANY_PUB, HIP_HIT_ANY_TMP and HIP_ENDPOINT_ANY.
first three equal to a HIT value associated with a wildcard HIT of The first three equal to a HIT value associated with a wildcard HIT
any, public, or anonymous type. The fourth macro, HIP_ADDR_ANY, of any type, public type, or anonymous type. The fourth constant,
denotes both HIP_HIT_ANY or any IPv4 or IPv6 address. The HIP_ENDPOINT_ANY, denotes that the application accepts both HIT and
HIP_HIT_ANY equals to HIP_HIT_ANY_PUB or HIP_HIT_ANY_TMP. The any other type of addresses. The HIP_HIT_ANY denotes that the
anonymous identifiers refer to the use anonymous identifiers as application accepts any type of HIT. The anonymous identifiers refer
specified in [RFC4423]. The system may designate anonymous to the use of anonymous identifiers as specified in [RFC4423]. The
identifiers as meta data associated with a HIT depending on whether system may designate anonymous identifiers as meta data associated
it has been published or not. However, there is no difference in the with a HIT depending on whether it has been published or not.
classes of HITs from the HIP protocol perspective, However, there is no difference in the classes of HITs from the
protocol perspective.
The application can use the HIP_HIT_ANY_* and HIP_ADDR_ANY macros to The application can use the HIP_HIT_ANY_* and HIP_ENDPOINT_ANY
accept incoming communications to all of the HITs of the local host. constants to accept incoming communications to all of the HITs of the
Incoming communications refers here to the functions such as bind(), local host. Incoming communications refers here to functions such as
recvfrom() and recvmsg(). The HIP_HIT_* macros are similar to the bind(), recvfrom() and recvmsg(). The HIP_HIT_* constants are
sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT, but they are similar to the sockets API constants INADDR_ANY and IN6ADDR_ANY_INIT,
applicable to HITs only. After initial contact with the peer, the but they are applicable to HITs only. After initial contact with the
application can discover the local and peer HITs using getsockname() peer, the application can discover the local and peer HITs using
and getpeername() calls in the context of connection oriented getsockname() and getpeername() calls in the context of connection
sockets. The difference between the use of the HIP_HIT_* and oriented sockets. The difference between the use of the HIP_HIT_*
HIP_ADDR_ANY macros here is that the former allows only HIP-based and HIP_ENDPOINT_ANY constants here is that the former allows only
communications but the latter also allows communications without HIP. HIP-based communications but the latter also allows communications
without HIP.
The application also uses the HIP_HIT_ANY macro in ship_hit field to The application also uses the HIP_HIT_ANY constant in ship_hit field
establish outgoing communications in Opportunistic mode [RFC5201], to establish outgoing communications in Opportunistic mode [RFC5201],
i.e., when the application knows the remote peer locator but not the i.e., when the application knows the remote peer locator but not the
HIT. Outgoing communications refers here to the use of functions HIT. Outgoing communications refers here to the use of functions
such as connect(), sendto() and sendmsg(). However, the application such as connect(), sendto() and sendmsg(). However, the application
should first associate the socket with at least one IP address of the should first associate the socket with at least one IP address of the
peer using SHIM_LOCLIST_PEER_PREF socket option. The use of the peer using SHIM_LOCLIST_PEER_PREF socket option. The use of the
HIP_HIT_ANY macro guarantees that the communications will be based on HIP_HIT_ANY constant guarantees that the communications will be based
HIP or none at all. on HIP or none at all.
The use of HIP_ADDR_ANY macro in the context of outgoing The use of HIP_ENDPOINT_ANY constant in the context of outgoing
communications is left for further experimentation. It could be used communications is left for further experimentation in the context of
for establishing a non-HIP based connectivity when HIP-based opportunistic mode. It can result in a data flow with or without
connectivity was unsuccessful. HIP.
Some applications rely on system level access control, either Some applications rely on system level access control, either
implicit or explicit (such as accept_filter() function found on BSD- implicit or explicit (such as accept_filter() function found on BSD-
based systems), but such discussion is out of scope. Other based systems), but such discussion is out of scope. Other
applications implement access control themselves by using the HITs. applications implement access control themselves by using the HITs.
In such a case, the application can compare two HITs using memcmp() In such a case, the application can compare two HITs contained in the
or similar function. It should be noticed that different connection ship_hit field using memcmp() or similar function. It should be
attempts between the same two hosts can result in different HITs noted that different connection attempts between the same two hosts
because a host is allowed to have multiple HITs. can result in different HITs because a host is allowed to have
multiple HITs.
4.2. Extensions to Resolver Data Structures 4.2. Extensions to Resolver Data Structures
The HIP APIs introduce a new addrinfo flag, HIP_PREFER_ORCHID, to be The HIP APIs introduce a new address family, AF_HIP, that HIP aware
used by application to query for both HIT and locator information via applications can use to control the address type returned from
the getaddrinfo() resolver function [RFC3493]. The getaddrinfo() getaddrinfo() function [RFC3493]. The getaddrinfo() function uses a
function uses a data structure used for both input to and output from data structure called addrinfo in its "hints" and "res" argument
the resolver. The data structure is illustrated in Figure 3. which are described in more detail in the next section. The addrinfo
data structure is illustrated in Figure 3.
#include <netdb.h> #include <netdb.h>
struct addrinfo { struct addrinfo {
int ai_flags; /* e.g. AI_EXTFLAGS */ int ai_flags; /* e.g. AI_EXTFLAGS */
int ai_family; /* e.g. AF_HIP */ int ai_family; /* e.g. AF_HIP */
int ai_socktype; /* e.g. SOCK_STREAM */ int ai_socktype; /* e.g. SOCK_STREAM */
int ai_protocol; /* 0 or IPPROTO_HIP */ int ai_protocol; /* 0 or IPPROTO_HIP */
socklen_t ai_addrlen; /* size of *ai_addr */ socklen_t ai_addrlen; /* size of *ai_addr */
struct sockaddr *ai_addr; /* sockaddr_hip */ struct sockaddr *ai_addr; /* sockaddr_hip */
char *ai_canonname; /* canon. name of the host */ char *ai_canonname; /* canon. name of the host */
struct addrinfo *ai_next; /* next endpoint */ struct addrinfo *ai_next; /* next endpoint */
int ai_eflags; /* RFC5014 extension */ int ai_eflags; /* RFC5014 extension */
}; };
Figure 3 Figure 3
Application must set both the flag AI_EXTFLAGS [RFC5014] in ai_flags An application resolving with the ai_family field set to AF_UNSPEC in
and HIP_PREFER_ORCHID in the ai_eflags, or otherwise the resolver the hints argument may receive any kind of socket address structures,
does not return sockaddr_hip data structures. The resolver returns including sockaddr_hip. When the application wants to receive only
EAI_BADFLAGS when it does not support HIP_PREFER_ORCHID or HITs contained in sockaddr_hip structures, it should set the
AI_EXTFLAGS flags. ai_family field to AF_HIP. Otherwise, the resolver does not return
any sockaddr_hip structures. The resolver returns EAI_FAMILY when
The system may have a HIP-aware interposing DNS agent as described in AF_HIP is not supported.
section 3.2 in [RFC5014]. In such a case, the DNS agent returns
transparently LSIs or HITs in sockaddr_in and sockaddr_in6 structures
when available. To disable this behaviour, the application sets
AI_EXTFLAGS and AI_NO_ORCHID flags.
Application denotes its preference for public and anonymous types of
HITs using HIP_PREFER_SRC_PUBLIC and HIP_PREFER_SRC_TMP flags in the
ai_eflags field. If the application sets neither of the flags, the
resolver returns both public and anonymous HITs.
The simultaneous use of both HIP_PREFER_ORCHID and The resolver ignores the AI_PASSIVE flag when the application sets
HIP_PREFER_PASSIVE_* flags produces a single sockaddr_hip structure the family in hints to AF_HIP.
containing a wildcard address that the application can use either for
incoming (node argument is NULL in getaddrinfo) or outgoing
communications (node argument is non-NULL). For example,
HIP_PREFER_PASSIVE_HIT_TMP flag produces one sockaddr_hip structure
that contains a HIP_HIT_ANY_TMP in the ship_hit field.
The resolver sets the ai_family field to AF_HIP in the addrinfo The system may have a HIP-aware interposing DNS agent as described in
structure when ai_addr points to a sockaddr_hip structure. section 3.2 in [RFC5338]. In such a case, the DNS agent may,
according to local policy, return transparently LSIs or HITs in
sockaddr_in and sockaddr_in6 structures when available. A HIP-aware
application can override this local policy in two ways. First, the
application can set the family to AF_HIP in the hints argument of
getaddrinfo() when it requests only sockaddr_hip structures. Second,
the application can set AI_EXTFLAGS and AI_NO_HIT flags to prevent
the resolver from returning HITs in any kind of data structures.
When ai_protocol field is set to zero, the resolver also returns When getaddrinfo() returns resolved outputs the results to res
locators in sockaddr_in and sockaddr_in6 structures in addition to argument, it sets the family to AF_HIP when the related structure is
sockaddr_hip structures. The resolver returns only sockaddr_hip sockaddr_hip.
structures when the application has set the ai_protocol field to
IPPROTO_HIP or a sockaddr_hip structure is given as the hint argument
to the resolver.
4.2.1. Resolver Usage 4.2.1. Resolver Usage
A HIP-aware application creates the sockaddr_hip structures A HIP-aware application creates the sockaddr_hip structures manually
explicitly or obtains them from the resolver. The explicit or obtains them from the resolver. The explicit configuration of
configuration of locators is described in locators is described in [I-D.ietf-shim6-multihome-shim-api]. This
[I-D.ietf-shim6-multihome-shim-api]. This document defines document defines "automated" resolver extensions for getaddrinfo()
"automated" resolver extensions for getaddrinfo() resolver [RFC3493]. resolver [RFC3493].
#include <netdb.h> #include <netdb.h>
int getaddrinfo(const char *nodename, int getaddrinfo(const char *nodename,
const char *servname, const char *servname,
const struct addrinfo *hints, const struct addrinfo *hints,
struct addrinfo **res) struct addrinfo **res)
void free_addrinfo(struct addrinfo *res) void free_addrinfo(struct addrinfo *res)
Figure 4 Figure 4
As described in [RFC3493], the getaddrinfo function takes the As described in [RFC3493], the getaddrinfo function takes the
nodename, servname, and hints as its input arguments. It places the nodename, servname, and hints as its input arguments. It places the
result of the query into the res argument. The return value is zero result of the query into the res output argument. The return value
on success, or a non-zero error value on error. The nodename is zero on success, or a non-zero error value on error. The nodename
argument specifies the host name to be resolved; a NULL argument argument specifies the host name to be resolved; a NULL argument
denotes the local host. The servname parameter declares the port denotes the HITs of the local host. The servname parameter declares
number to be set in the socket addresses in the res output argument. the port number to be set in the socket addresses in the res output
Both the nodename and servname cannot be NULL. argument. Both the nodename and servname cannot be NULL at the same
time.
The input argument "hints" acts like a filter that defines the The input argument "hints" acts like a filter that defines the
attributes required from the resolved endpoints. A NULL hints attributes required from the resolved endpoints. A NULL hints
argument indicates that any kind of endpoints are acceptable. argument indicates that any kind of endpoints are acceptable.
The output argument "res" is dynamically allocated by the resolver. The output argument "res" is dynamically allocated by the resolver.
The application frees res argument with the free_addrinfo function. The application frees the res argument with the free_addrinfo
The res argument contains a linked list of the resolved endpoints. function. The res argument contains a linked list of the resolved
The linked list contains sockaddr_hip structures only when the input endpoints. The linked list contains sockaddr_hip structures only
argument has the HIP_PREFER_ORCHID flag set in ai_eflags. The when the input argument has the family set to AF_HIP. When the
resolver inserts HITs before any locators. When the family is zero, the list contains sockaddr_hip structures before
HIP_PREFER_ORCHID flag is set, the resolver does not return LSIs or sockaddr_in and sockaddr_in6 structures.
HITs encapsulated into sockaddr_in or sockaddr_in6 data structures as
described in [RFC5338].
Resolver can return a HIT which maps to multiple locators. The Resolver can return a HIT which maps to multiple locators. The
resolver may cache the locator mappings to the HIP module. The HIP resolver may cache the locator mappings with the HIP module. The HIP
module manages the multiple locators according to system policies of module manages the multiple locators according to system policies of
the host. The multihoming document the host. The multihoming document
[I-D.ietf-shim6-multihome-shim-api] describes how an application can [I-D.ietf-shim6-multihome-shim-api] describes how an application can
override system default policies. override system default policies.
It should be noticed that the application can configure the HIT It should be noted that the application can configure the HIT
explicitly without setting the locator or the resolver can fail to explicitly without setting the locator or the resolver can fail to
resolve any locator. In this scenario, the application relies on the resolve any locator. In this scenario, the application relies on the
system to map the HIT to an IP address. When the system fails to system to map the HIT to an IP address. When the system fails to
provide the mapping, it returns -1 in the called sockets API function provide the mapping, it returns -1 in the called sockets API function
to the application and sets errno to EADDRNOTAVAIL. to the application and sets errno to EADDRNOTAVAIL.
4.3. The Use of getsockname and getpeername Functions 4.3. The Use of getsockname and getpeername Functions
The application usually discovers the local or peer HITs from the The application usually discovers the local or peer HITs from the
sockaddr_hip structures returned by getaddrinfo(). However, the sockaddr_hip structures returned by getaddrinfo(). However, the
sockaddr_hip structure does not contain a HIT when the application sockaddr_hip structure does not contain a HIT when the application
uses the HIP_HIT_ANY_* macros. In such a case, the application uses the HIP_HIT_ANY_* constants. In such a case, the application
discovers the local and peer HITs using the getsockname() and discovers the local and peer HITs using the getsockname() and
getpeername() functions. The functions return sockaddr_hip getpeername() functions. The functions return sockaddr_hip
structures when the family of the socket is AF_HIP. structures when the family of the socket is AF_HIP.
4.4. Validating HITs 4.4. Selection of Source HIT Type
An application that uses the HIP_ADDR_ANY macro may want to check if
the local or peer address is an orchid-based HIT [RFC4843]. Also,
the application may want to verify whether a HIT is public or
anonymous. The application accomplishes these using a new function
called sockaddr_is_srcaddr() which is illustrated in Figure 5.
#include <netinet/in.h>
short sockaddr_is_srcaddr(struct sockaddr *srcaddr
uint64_t flags);
Figure 5 The Socket API for Source Address Selection [RFC5014] defines socket
The sockaddr_is_srcaddr() function operates in the same way as options to allow applications to influence source address selection
inet6_is_srcaddr() function [RFC5014] which can be used to verify the mechanisms. In some cases, HIP-aware applications may want to
type of an address belonging to the localhost. The difference is influence source HIT selection; in particular, whether an outbound
that sockaddr_is_srcaddr() function handles sockaddr_hip structures connection should use a published or anonymous HIT. Similar to
in addition to sockaddr_in6, and possibly some other socket IPV6_ADDR_PREFERENCES defined in RFC 5014, the following socket
structures in further extensions. The function has also 64 bit flags option HIT_PREFERENCES is defined for HIP-based sockets. This socket
instead of 32 bits. This new function handles the same flags as option can be used with setsockopt() and getsockopt() calls to set
defined in [RFC5014] in addition to some HIP-specific flags listed in and get the HIT selection preferences affecting a HIP-enabled socket.
Table 2. The socket option value (optval) is a 32-bit unsigned integer
argument. The argument consists of a number of flags where each flag
indicates an address selection preference that modifies one of the
rules in the default HIT selection; these flags are shown in Table 2.
+-----------------------+-------------------------+ +---------------------------+-------------------------+
| Flag | Purpose | | Socket Option | Purpose |
+-----------------------+-------------------------+ +---------------------------+-------------------------+
| HIP_PREFER_ORCHID | The identifier is a HIT | | HIP_PREFER_SRC_HIT_TMP | Prefer an anonymous HIT |
| HIP_PREFER_SRC_TMP | Anonymous HIT | | HIP_PREFER_SRC_HIT_PUBLIC | Prefer a public HIT |
| HIP_PREFER_SRC_PUBLIC | Public HIT | +---------------------------+-------------------------+
+-----------------------+-------------------------+
Table 2 Table 2
4.5. Source HIT Selection by the System If the system is unable to assign the type of HIT that is requested,
at HIT selection time, the socket call (connect (), sendto(), or
sendmsg()) will fail and errno will be set to EINVAL. If the
application tries to set both of the above flags for the same socket,
this also results in the error EINVAL.
Some applications initiate communications by specifying only the 4.5. Verification of Source HIT Type
destination identifier and let the underlying system specify the
source. When the system selects the source HIT, the system should
apply the rules specified in [RFC3484] according to the default
policy table for HITs shown in Table 3.
+-----------------+------------+-------+ An application that uses the HIP_ENDPOINT_ANY constant may want to
| HIT Type | Precedence | Label | check whether the actual communications was based on HIP or not.
+-----------------+------------+-------+ Also, the application may want to verify whether a local HIT is
| Anonymous DSA | 110 | 5 | public or anonymous. The application accomplishes these using a new
| Anonymous RSA | 120 | 6 | function called sockaddr_is_srcaddr() which is illustrated in
| Public DSA | 130 | 7 | Figure 5.
| Public RSA | 140 | 8 |
| [RFC3484] rules | 50-100 | 7 |
+-----------------+------------+-------+
Table 3 #include <netinet/in.h>
When application using a AF_HIP-based socket does not specify the short sockaddr_is_srcaddr(struct sockaddr *srcaddr,
source identifier, the system selects the source identifier on the uint64_t flags);
behalf of the application according to the precedence in the above
table. For example, the system prefers public (published) keys
before anonymous keys because they work better for referral purposes.
RSA-based keys are preferred over DSA based because RSA is the
default algorithm in HIP.
When system provides multiple keys of same type, but with different Figure 5
key lengths, the longer keys should have a higher preference. As
example, system providing two public RSA keys of different size would
give the smaller key preference value 140 and 145 for the larger.
The preference value should not exceed 150. Systems supporting more
than 10 keys of same key size may use digits to further fragment the
precedence namespace. IPv6 addresses have the lowest precedence
value to denote that HITs have a higher precedence when operating on
AF_HIP-based sockets.
[RFC5014] specifies flags for the getaddrinfo resolver and socket The sockaddr_is_srcaddr() function operates in the same way as
options for Mobile IPv6. The resolver, operating under inet6_is_srcaddr() function [RFC5014] which can be used to verify the
HIP_PREFER_ORCHID flag, or the socket handler, operating on a AF_HIP- type of an address belonging to the local host. The difference is
based socket, may encounter such flags or options. In such a case that the sockaddr_is_srcaddr() function handles sockaddr_hip
the resolver or socket handler should silenty ignore the flags or structures in addition to sockaddr_in6, and possibly some other
options without returning an error. However, a HIP-aware application socket structures in further extensions. The flags argument is also
may use the HIP-specific flags HIP_PREFER_ORCHID, HIP_PREFER_SRC_TMP 64 bit instead of 32 bits because new function handles the same flags
or HIP_PREFER_SRC_PUBLIC in getsockopt(), setsockopt(), getaddrinfo() as defined in [RFC5014] in addition to two HIP-specific flags,
calls and in the anchillary data of datagram packets as specified in HIP_PREFER_SRC_HIT_TMP and HIP_PREFER_SRC_HIT_PUBLIC. With these two
[RFC5014]. The level of the socket options should be set to SOL_SHIM flags, the application can distinguish anonymous HITs from public
[I-D.ietf-shim6-multihome-shim-api] and the option name should be HITs.
HIP_HIT_PREFERENCES.
When given an AF_INET6 socket, sockaddr_is_srcaddr() behaves as
inet6_is_srcaddr() function as described in [RFC5014]. With AF_HIP
socket, the function returns 1 when the HIT contained in the socket
address structure corresponds to a valid HIT of the local host and
the HIT satisfies the given flags. The function returns -1 when the
HIT does not belong to the local host or the flags are not valid.
The function returns 0 when the preference flags are valid but the
HIT does not match the given flags.
4.6. Explicit Handling of Locators 4.6. Explicit Handling of Locators
The system resolver, or the HIP module, maps HITs to locators The system resolver, or the HIP module, maps HITs to locators
implicitly. However, some applications may want to specify initial implicitly. However, some applications may want to specify initial
locator mappings explicitly. In such a case, the application first locator mappings explicitly. In such a case, the application first
creates a socket with AF_HIP as the domain argument. Second, the creates a socket with AF_HIP as the domain argument. Second, the
application may set locator information with one of the following application may get or set locator information with one of the
shim socket options as defined in the multihoming extensions in following shim socket options as defined in the multihoming
[I-D.ietf-shim6-multihome-shim-api]: extensions in [I-D.ietf-shim6-multihome-shim-api]. The related
socket options are summarized briefly in Table 3.
+-----------------------------+-----+-----+-----------------+-------+
| optname | get | set | description | dtype |
+-----------------------------+-----+-----+-----------------+-------+
| SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 |
| | | | preferred | |
| | | | locator on the | |
| | | | local side for | |
| | | | the context | |
| | | | associated with | |
| | | | the socket. | |
| SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 |
| | | | preferred | |
| | | | locator on the | |
| | | | remote side for | |
| | | | the context | |
| | | | associated with | |
| | | | the socket. | |
| SHIM_LOCLIST_LOCAL | o | o | Get or set a | *2 |
| | | | list of | |
| | | | locators | |
| | | | associated with | |
| | | | the local EID. | |
| SHIM_LOCLIST_PEER | o | o | Get or set a | *2 |
| | | | list of | |
| | | | locators | |
| | | | associated with | |
| | | | the peer's EID. | |
| SHIM_LOC_LOCAL_SEND | o | o | Request use of | *2 |
| | | | specific | |
| | | | locator as | |
| | | | source locator | |
| | | | of outgoing IP | |
| | | | packets. | |
| SHIM_LOC_PEER_SEND | o | o | Request use of | *2 |
| | | | specific | |
| | | | locator as | |
| | | | destination | |
| | | | locator of | |
| | | | outgoing IP | |
| | | | packets. | |
+-----------------------------+-----+-----+-----------------+-------+
*1: Pointer to a shim_locator which is defined in Section 7 of
draft-ietf-shim6-multihome-shim-api.
*2: Pointer to an array of shim_locator.
Figure 6
Finally, the application creates a valid sockaddr_hip structure and
associates the socket also with the sockaddr_hip structure by calling
some socket-related function, such as connect() or bind().
The usage and semantics for typical use cases are as follows: +---------------------+---------------------------------------------+
| optname | description |
+---------------------+---------------------------------------------+
| SHIM_LOC_LOCAL_PREF | Get or set the preferred locator on the |
| | local side for the context associated with |
| | the socket. |
| SHIM_LOC_PEER_PREF | Get or set the preferred locator on the |
| | remote side for the context associated with |
| | the socket. |
| SHIM_LOCLIST_LOCAL | Get or set a list of locators associated |
| | with the local EID. |
| SHIM_LOCLIST_PEER | Get or set a list of locators associated |
| | with the peer's EID. |
| SHIM_LOC_LOCAL_SEND | Set or get the default source locator of |
| | outgoing IP packets. |
| SHIM_LOC_PEER_SEND | Set or get the default destination locator |
| | of outgoing IP packets. |
+---------------------+---------------------------------------------+
An application that initiates a connection using a connection Table 3
oriented socket to a particular host at a known address or set of
addresses can invoke SHIM_LOCLIST_PEER socket option. The HIP module
uses the first address (if multiple are provided, or else the
application can override this by setting SHIM_LOC_PEER_PREF to one of
the addresses in SHIM_LOCLIST_PEER. The application later provides a
specific HIT in the ship_hit field of the sockaddr_hip in the
connect() system call. If the application provides one or more
addresses in SHIM_LOCLIST_PEER setsockopt call, the system should not
connect to the host via another destination address, in case the
application intends to restrict the range of addresses permissible as
a policy choice. If the system cannot reach the provided HIT at one
of the addresses provided, the outbound socket API functions
(connect, sendmsg, etc.) return -1 and set errno to EINVALIDLOCATOR.
Another common use case is to set up an association in opportunistic As an example of locator mappings, a connection-oriented application
mode, when the destination HIT is specified as a wildcard. This can creates a HIP-based socket and sets the SHIM_LOCLIST_PEER socket
be accomplished by setting one or more destination addresses using option to the socket. The HIP module uses the first address
the SHIM_LOCLIST_PEER socket option as described above and then contained in the option if multiple are provided. If the application
calling connect() with the wildcard HIT. The connect() call returns provides one or more addresses in the SHIM_LOCLIST_PEER setsockopt
-1 and sets errno to EADDRNOTAVAIL when the application connects to a call, the system should not connect to the host via another
wildcard without specifying any destination address. destination address, in case the application intends to restrict the
range of addresses permissible as a policy choice. The application
can override the default peer locator by setting the
SHIM_LOC_PEER_PREF socket option if necessary. Finally, the
application provides a specific HIT in the ship_hit field of the
sockaddr_hip in the connect() system call. If the system cannot
reach the HIT at one of the addresses provided, the outbound socket
API functions (connect, sendmsg, etc.) return -1 and set errno to
EINVALIDLOCATOR.
Applications may also choose to associate local addresses with Applications may also choose to associate local addresses with
sockets. The procedures specified in sockets. The procedures specified in
[I-D.ietf-shim6-multihome-shim-api] are followed in this case. [I-D.ietf-shim6-multihome-shim-api] are followed in this case.
Another use case is to use the opportunistic mode when the
destination HIT is specified as a wildcard. The application sets one
or more destination addresses using the SHIM_LOCLIST_PEER socket
option as described above and then calls connect() with the wildcard
HIT. The connect() call returns -1 and sets errno to EADDRNOTAVAIL
when the application connects to a wildcard without specifying any
destination address.
Applications using datagram-oriented sockets can use ancillary data
to control the locators. This described in detail in
[I-D.ietf-shim6-multihome-shim-api].
5. Summary of New Definitions 5. Summary of New Definitions
Table 4 summarizes the new macro and structures defined in this Table 4 summarizes the new constants and structures defined in this
document. document.
+-----------------+-----------------------------+ +-----------------+---------------------+
| Header | Definition | | Header | Definition |
+-----------------+-----------------------------+ +-----------------+---------------------+
| <sys/socket.h> | AF_HIP | | <sys/socket.h> | AF_HIP |
| <sys/socket.h> | PF_HIP | | <sys/socket.h> | PF_HIP |
| <netinet/in.h> | IPPROTO_HIP | | <netinet/in.h> | IPPROTO_HIP |
| <netinet/hip.h> | HIP_HIT_ANY | | <netinet/hip.h> | HIP_HIT_ANY |
| <netinet/hip.h> | HIP_HIT_ANY_PUB | | <netinet/hip.h> | HIP_HIT_ANY_PUB |
| <netinet/hip.h> | HIP_HIT_ANY_TMP | | <netinet/hip.h> | HIP_HIT_ANY_TMP |
| <netinet/hip.h> | HIP_ADDR_ANY | | <netinet/hip.h> | HIP_ENDPOINT_ANY |
| <netinet/hip.h> | HIP_HIT_PREFERENCES | | <netinet/hip.h> | HIP_HIT_PREFERENCES |
| <netinet/hip.h> | hip_hit_t | | <netinet/hip.h> | hip_hit_t |
| <netdb.h> | HIP_PREFER_ORCHID | | <netdb.h> | AI_NO_HIT |
| <netdb.h> | HIP_PREFER_SRC_TMP |
| <netdb.h> | HIP_PREFER_SRC_PUBLIC |
| <netdb.h> | HIP_PREFER_PASSIVE_HIT_TMP |
| <netdb.h> | HIP_PREFER_PASSIVE_HIT_PUB |
| <netdb.h> | HIP_PREFER_PASSIVE_HIT_ANY |
| <netdb.h> | HIP_PREFER_PASSIVE_ADDR_ANY |
| <netinet/hip.h> | sockaddr_hip | | <netinet/hip.h> | sockaddr_hip |
| <netinet/hip.h> | sockaddr_is_srcaddr | | <netinet/hip.h> | sockaddr_is_srcaddr |
+-----------------+-----------------------------+ +-----------------+---------------------+
Table 4 Table 4
6. IANA Considerations 6. IANA Considerations
No IANA considerations. No IANA considerations.
7. Security Considerations 7. Security Considerations
No security considerations currently. No security considerations currently.
skipping to change at page 15, line 48 skipping to change at page 15, line 10
8. Contributors 8. Contributors
Thanks for Jukka Ylitalo and Pekka Nikander for their original Thanks for Jukka Ylitalo and Pekka Nikander for their original
contribution, time and effort to the native HIP APIs. Thanks for contribution, time and effort to the native HIP APIs. Thanks for
Yoshifuji Hideaki for his contributions to this document. Yoshifuji Hideaki for his contributions to this document.
9. Acknowledgements 9. Acknowledgements
Kristian Slavov, Julien Laganier, Jaakko Kangasharju, Mika Kousa, Jan Kristian Slavov, Julien Laganier, Jaakko Kangasharju, Mika Kousa, Jan
Melen, Andrew McGregor, Sasu Tarkoma, Lars Eggert, Joe Touch, Antti Melen, Andrew McGregor, Sasu Tarkoma, Lars Eggert, Joe Touch, Antti
Jaervinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keraenen, Jarvinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keranen,
Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Jan Melen and Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Joakim Koskela,
Gonzalo Camarillo have also provided valuable ideas or feedback. Jeff Ahrenholz and Gonzalo Camarillo have also provided valuable
Thanks also for the APPS area folks, including Stephane Bortzmeyer, ideas or feedback. Thanks also for the APPS area folks, including
Chris Newman, Tony Finch, "der Mouse" and Keith Moore. Stephane Bortzmeyer, Chris Newman, Tony Finch, "der Mouse" and Keith
Moore.
10. Normative References 10. Normative References
[I-D.ietf-btns-c-api] [I-D.ietf-btns-c-api]
Richardson, M., Williams, N., Komu, M., and S. Tarkoma, Richardson, M., Williams, N., Komu, M., and S. Tarkoma,
"C-Bindings for IPsec Application Programming Interfaces", "C-Bindings for IPsec Application Programming Interfaces",
draft-ietf-btns-c-api-04 (work in progress), March 2009. draft-ietf-btns-c-api-04 (work in progress), March 2009.
[I-D.ietf-shim6-multihome-shim-api] [I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
skipping to change at page 16, line 31 skipping to change at page 15, line 39
[I-D.ietf-shim6-proto] [I-D.ietf-shim6-proto]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
in progress), February 2009. in progress), February 2009.
[POSIX] Institute of Electrical and Electronics Engineers, "IEEE [POSIX] Institute of Electrical and Electronics Engineers, "IEEE
Std. 1003.1-2001 Standard for Information Technology - Std. 1003.1-2001 Standard for Information Technology -
Portable Operating System Interface (POSIX)", Dec 2001. Portable Operating System Interface (POSIX)", Dec 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
skipping to change at page 17, line 17 skipping to change at page 16, line 24
April 2008. April 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, Identity Protocol with Legacy Applications", RFC 5338,
September 2008. September 2008.
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsaenneidonkuja 4 Metsanneidonkuja 4
Helsinki Helsinki
Finland Finland
Phone: +358503841531 Phone: +358503841531
Fax: +35896949768 Fax: +35896949768
Email: miika@iki.fi Email: miika@iki.fi
URI: http://www.iki.fi/miika/ URI: http://www.iki.fi/miika/
Thomas Henderson Thomas Henderson
The Boeing Company The Boeing Company
 End of changes. 67 change blocks. 
340 lines changed or deleted 288 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/