draft-ietf-hip-native-api-07.txt   draft-ietf-hip-native-api-08.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: January 14, 2010 Henderson Expires: January 31, 2010 Henderson
The Boeing Company The Boeing Company
July 13, 2009 July 30, 2009
Basic Socket Interface Extensions for Host Identity Protocol (HIP) Basic Socket Interface Extensions for Host Identity Protocol (HIP)
draft-ietf-hip-native-api-07 draft-ietf-hip-native-api-08
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 January 14, 2010. This Internet-Draft will expire on January 31, 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
With the extensions, the application can also support more relaxed With the extensions, the application can also support more relaxed
security models where the communication can be non-HIP based, security models where the communication can be non-HIP based,
according to local policies. The extensions in document are according to local policies. The extensions in document are
experimental and provide basic tools for further experimentation with experimental and provide basic tools for further experimentation with
policies. policies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. API Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Name Resolution Process . . . . . . . . . . . . . . . . . . . 5
3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5 3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5
3.2. Interaction without a Resolver . . . . . . . . . . . . . . 6 3.2. Interaction without a Resolver . . . . . . . . . . . . . . 6
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 7 4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 7
4.1. Socket Family and Address Structure Extensions . . . . . . 7 4.1. Socket Family and Address Structure Extensions . . . . . . 7
4.2. Extensions to Resolver Data Structures . . . . . . . . . . 9 4.2. Extensions to Resolver Data Structures . . . . . . . . . . 9
4.3. The Use of getsockname and getpeername Functions . . . . . 11 4.3. The Use of getsockname and getpeername Functions . . . . . 11
4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 11 4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 11
4.5. Verification of Source HIT Type . . . . . . . . . . . . . 12 4.5. Verification of Source HIT Type . . . . . . . . . . . . . 12
4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 12 4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 13
5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 14 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 5, line 5 skipping to change at page 5, line 5
| 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 |
| | a 28 bit prefix | | | a 28 bit prefix |
| LSI | Local Scope Identifier, a local, 32-bit descriptor for | | LSI | Local Scope Identifier, a local, 32-bit descriptor for |
| | a given public key. | | | a given public key. |
| Locator | Routable IPv4 or IPv6 address used at the lower layers | | Locator | Routable IPv4 or IPv6 address used at the lower layers |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
Table 1 Table 1
3. API Overview 3. Name Resolution Process
This section provides an overview of how the API can be used. First, This section provides an overview of how the API can be used. First,
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
skipping to change at page 7, line 26 skipping to change at page 7, line 26
a new address family, AF_HIP. The AF_HIP and PF_HIP are aliases to a new address family, AF_HIP. The AF_HIP and PF_HIP are aliases to
each other. These definition shall be defined as a result of each other. These definition shall be defined as a result of
including <sys/socket.h>. including <sys/socket.h>.
The use of the PF_HIP constant is mandatory with the socket() The use of the PF_HIP constant is mandatory with the socket()
function when an application uses the native HIP APIs. The function when an application uses the native HIP APIs. The
application gives the PF_HIP constant as the first argument (domain) application gives the PF_HIP constant as the first argument (domain)
to the socket() function. The system returns a positive integer to the socket() function. The system returns a positive integer
representing a socket descriptor when the system supports HIP. representing a socket descriptor when the system supports HIP.
Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT. Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT.
This is the default behavior for unsupported address families and
does not require any changes to legacy systems.
Figure 2 shows socket address structure for HIP. Figure 2 shows socket address structure for HIP.
#include <netinet/in.h> #include <netinet/in.h>
typedef struct in6_addr hip_hit_t; typedef struct in6_addr hip_hit_t;
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 4.3BSD format. The family of the socket, ship_family,
ship_family, is set to AF_HIP. The port number ship_port is two is set to AF_HIP. The port number ship_port is two octets in network
octets in network byte order and the ship_hit is 16 octets in network byte order and the ship_hit is 16 octets in network byte order. An
byte order. An implementation may have extra member(s) in this implementation may have extra member(s) in 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 constants to set a However, the application can use three special constants to set a
wildcard value manually into the ship_hit field. The constants 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_ENDPOINT_ANY. HIP_HIT_ANY, HIP_HIT_ANY_PUB, HIP_HIT_ANY_TMP and HIP_ENDPOINT_ANY.
The first three equal to a HIT value associated with a wildcard HIT The first three equal to a HIT value associated with a wildcard HIT
of any type, public type, or anonymous type. The fourth constant, of any type, public type, or anonymous type. The fourth constant,
HIP_ENDPOINT_ANY, denotes that the application accepts both HIT and HIP_ENDPOINT_ANY, denotes that the application accepts HIT, IPv4 and
any other type of addresses. The HIP_HIT_ANY denotes that the IPv6-based addresses. The HIP_HIT_ANY denotes that the application
application accepts any type of HIT. The anonymous identifiers refer accepts any type of HIT. The anonymous identifiers refer to the use
to the use of anonymous identifiers as specified in [RFC4423]. The of anonymous identifiers as specified in [RFC4423]. The system may
system may designate anonymous identifiers as meta data associated designate anonymous identifiers as meta data associated with a HIT
with a HIT depending on whether it has been published or not. depending on whether it has been published or not. However, there is
However, there is no difference in the classes of HITs from the no difference in the classes of HITs from the protocol perspective.
protocol perspective.
The application can use the HIP_HIT_ANY_* and HIP_ENDPOINT_ANY The application can use the HIP_HIT_ANY_* and HIP_ENDPOINT_ANY
constants to accept incoming communications to all of the HITs of the constants to accept incoming communications to all of the HITs of the
local host. Incoming communications refers here to functions such as local host. Incoming communications refers here to functions such as
bind(), recvfrom() and recvmsg(). The HIP_HIT_* constants are bind(), recvfrom() and recvmsg(). The HIP_HIT_* constants are
similar to the sockets API constants INADDR_ANY and IN6ADDR_ANY_INIT, similar to the sockets API constants INADDR_ANY and IN6ADDR_ANY_INIT,
but they are applicable to HITs only. After initial contact with the but they are applicable to HITs only. After initial contact with the
peer, the application can discover the local and peer HITs using peer, the application can discover the local and peer HITs using
getsockname() and getpeername() calls in the context of connection getsockname() and getpeername() calls as described in Section 4.3.
oriented sockets. The difference between the use of the HIP_HIT_* The difference between the use of the HIP_HIT_* and HIP_ENDPOINT_ANY
and HIP_ENDPOINT_ANY constants here is that the former allows only constants here is that the former allows only HIP-based
HIP-based communications but the latter also allows communications communications but the latter also allows communications without HIP.
without HIP.
When a connection-oriented server application binds to
HIP_ENDPOINT_ANY and calls accept(), the call outputs always a
sockaddr_hip structure containing information on the connected client
with the address family set to AF_HIP. The same applies also to
datagram-oriented recvfrom() and recvmsg() calls. If the data flow
was based on HIP, the ship_hit field contains a HIT. In the case of
an IPv6 data flow without HIP, the field contains the corresponding
IPv6 address of the client. In the case of an IPv4 flow without HIP,
the fields contains the client's IPv4 address in IPv4-mapped IPv6
address format as described in section 3.7 of [RFC3493]. Section 4.5
describes how the application can verify the type of the address
returned by the socket API calls.
The application also uses the HIP_HIT_ANY constant in ship_hit field The application also uses the HIP_HIT_ANY constant in ship_hit field
to 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 constant guarantees that the communications will be based HIP_HIT_ANY constant guarantees that the communications will be based
on HIP or none at all. on HIP or none at all.
skipping to change at page 9, line 18 skipping to change at page 9, line 30
The HIP APIs introduce a new address family, AF_HIP, that HIP aware The HIP APIs introduce a new address family, AF_HIP, that HIP aware
applications can use to control the address type returned from applications can use to control the address type returned from
getaddrinfo() function [RFC3493]. The getaddrinfo() function uses a getaddrinfo() function [RFC3493]. The getaddrinfo() function uses a
data structure called addrinfo in its "hints" and "res" argument data structure called addrinfo in its "hints" and "res" argument
which are described in more detail in the next section. The addrinfo which are described in more detail in the next section. The addrinfo
data structure is illustrated in Figure 3. 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_CANONNAME */
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 */
}; };
skipping to change at page 9, line 49 skipping to change at page 10, line 13
The resolver ignores the AI_PASSIVE flag when the application sets The resolver ignores the AI_PASSIVE flag when the application sets
the family in hints to AF_HIP. the family in hints to AF_HIP.
The system may have a HIP-aware interposing DNS agent as described in The system may have a HIP-aware interposing DNS agent as described in
section 3.2 in [RFC5338]. In such a case, the DNS agent may, section 3.2 in [RFC5338]. In such a case, the DNS agent may,
according to local policy, return transparently LSIs or HITs in according to local policy, return transparently LSIs or HITs in
sockaddr_in and sockaddr_in6 structures when available. A HIP-aware sockaddr_in and sockaddr_in6 structures when available. A HIP-aware
application can override this local policy in two ways. First, the application can override this local policy in two ways. First, the
application can set the family to AF_HIP in the hints argument of application can set the family to AF_HIP in the hints argument of
getaddrinfo() when it requests only sockaddr_hip structures. Second, getaddrinfo() when it requests only sockaddr_hip structures. Second,
the application can set AI_EXTFLAGS and AI_NO_HIT flags to prevent the application can set AI_NO_HIT flag to prevent the resolver from
the resolver from returning HITs in any kind of data structures. returning HITs in any kind of data structures.
When getaddrinfo() returns resolved outputs the results to res When getaddrinfo() returns resolved outputs the results to res
argument, it sets the family to AF_HIP when the related structure is argument, it sets the family to AF_HIP when the related structure is
sockaddr_hip. sockaddr_hip.
4.2.1. Resolver Usage 4.2.1. Resolver Usage
A HIP-aware application creates the sockaddr_hip structures manually A HIP-aware application creates the sockaddr_hip structures manually
or obtains them from the resolver. The explicit configuration of or obtains them from the resolver. The explicit configuration of
locators is described in [I-D.ietf-shim6-multihome-shim-api]. This locators is described in [I-D.ietf-shim6-multihome-shim-api]. This
skipping to change at page 10, line 49 skipping to change at page 11, line 13
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 the res argument with the free_addrinfo The application frees the res argument with the free_addrinfo
function. The res argument contains a linked list of the resolved function. The res argument contains a linked list of the resolved
endpoints. The linked list contains sockaddr_hip structures only endpoints. The linked list contains sockaddr_hip structures only
when the input argument has the family set to AF_HIP. When the when the input argument has the family set to AF_HIP. When the
family is zero, the list contains sockaddr_hip structures before family is zero, the list contains sockaddr_hip structures before
sockaddr_in and sockaddr_in6 structures. sockaddr_in and sockaddr_in6 structures.
Resolver can return a HIT which maps to multiple locators. The The resolver can return a HIT which maps to multiple locators. The
resolver may cache the locator mappings with 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 noted 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 sockaddr_hip structure does not contain a HIT when the
sockaddr_hip structures returned by getaddrinfo(). However, the application uses the HIP_HIT_ANY_* or HIP_ENDPOINT_ANY constants. In
sockaddr_hip structure does not contain a HIT when the application such a case, the application can discover the local and peer HITs
uses the HIP_HIT_ANY_* constants. In such a case, the application using the getsockname() and getpeername() functions after the socket
discovers the local and peer HITs using the getsockname() and is connected. The functions getsockname() and getpeername() always
getpeername() functions. The functions return sockaddr_hip output a sockaddr_hip structure when the family of the socket is
structures when the family of the socket is AF_HIP. AF_HIP. The application should be prepared to handle also IPv4 and
IPv6 addresses in the ship_hit field as described in Section 4.1 in
the context of the HIP_ENDPOINT_ANY constant.
4.4. Selection of Source HIT Type 4.4. Selection of Source HIT Type
A client-side application can choose its source HIT by e.g. querying
all of the local HITs with getaddrinfo() and associating one of them
with the socket using bind(). This section describes another method
for a client-side application to affect the selection of the source
HIT type where the application does not call bind() explicitly.
Instead, the application just specifies the preferred requirements
for the source HIT type.
The Socket API for Source Address Selection [RFC5014] defines socket The Socket API for Source Address Selection [RFC5014] defines socket
options to allow applications to influence source address selection options to allow applications to influence source address selection
mechanisms. In some cases, HIP-aware applications may want to mechanisms. In some cases, HIP-aware applications may want to
influence source HIT selection; in particular, whether an outbound influence source HIT selection; in particular, whether an outbound
connection should use a published or anonymous HIT. Similar to connection should use a published or anonymous HIT. Similar to
IPV6_ADDR_PREFERENCES defined in RFC 5014, the following socket IPV6_ADDR_PREFERENCES defined in RFC 5014, the following socket
option HIT_PREFERENCES is defined for HIP-based sockets. This socket option HIT_PREFERENCES is defined for HIP-based sockets. This socket
option can be used with setsockopt() and getsockopt() calls to set option can be used with setsockopt() and getsockopt() calls to set
and get the HIT selection preferences affecting a HIP-enabled socket. and get the HIT selection preferences affecting a HIP-enabled socket.
The socket option value (optval) is a 32-bit unsigned integer The socket option value (optval) is a 32-bit unsigned integer
skipping to change at page 14, line 42 skipping to change at page 15, line 30
+-----------------+---------------------+ +-----------------+---------------------+
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. The use of HIP_ENDPOINT_ANY can be used to accept incoming or create
outgoing data flows without HIP. The application should use the
sockaddr_is_srcaddr() function to validate the type of the connection
in order to e.g. inform the user of the lack of HIP-based security.
The use of the HIP_HIT_ANY_* constants is recommended in security-
critical applications and systems.
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
Jarvinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keranen, Jarvinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keranen,
Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Joakim Koskela, Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Joakim Koskela,
Jeff Ahrenholz and Gonzalo Camarillo have also provided valuable Jeff Ahrenholz, Tobias Heer and Gonzalo Camarillo have provided
ideas or feedback. Thanks also for the APPS area folks, including valuable ideas and feedback. Thanks also for the APPS area folks,
Stephane Bortzmeyer, Chris Newman, Tony Finch, "der Mouse" and Keith including Stephane Bortzmeyer, Chris Newman, Tony Finch, "der Mouse"
Moore. 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,
"Socket Application Program Interface (API) for "Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-08 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-09
(work in progress), May 2009. (work in progress), July 2009.
[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.
 End of changes. 21 change blocks. 
48 lines changed or deleted 75 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/