draft-ietf-hip-native-api-10.txt   draft-ietf-hip-native-api-11.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: June 13, 2010 T. Henderson Expires: July 2, 2010 T. Henderson
The Boeing Company The Boeing Company
December 10, 2009 December 29, 2009
Basic Socket Interface Extensions for Host Identity Protocol (HIP) Basic Socket Interface Extensions for Host Identity Protocol (HIP)
draft-ietf-hip-native-api-10 draft-ietf-hip-native-api-11
Abstract Abstract
This document defines extensions to the current sockets API for the This document defines extensions to the current sockets API for the
Host Identity Protocol (HIP). The extensions focus on the use of Host Identity Protocol (HIP). The extensions focus on the use of
public-key based identifiers discovered via DNS resolution, but public-key based identifiers discovered via DNS resolution, but
define also interfaces for manual bindings between HITs and locators. define also interfaces for manual bindings between HITs and locators.
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 this document are according to local policies. The extensions in this document are
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 June 13, 2010. This Internet-Draft will expire on July 2, 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Name Resolution Process . . . . . . . . . . . . . . . . . . . 6 3. Name Resolution Process . . . . . . . . . . . . . . . . . . . 6
3.1. Interaction with the Resolver . . . . . . . . . . . . . . 6 3.1. Interaction with the Resolver . . . . . . . . . . . . . . 6
3.2. Interaction without a Resolver . . . . . . . . . . . . . . 7 3.2. Interaction without a Resolver . . . . . . . . . . . . . . 7
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 8 4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 8
4.1. Socket Family and Address Structure Extensions . . . . . . 8 4.1. Socket Family and Address Structure Extensions . . . . . . 8
4.2. Extensions to Resolver Data Structures . . . . . . . . . . 10 4.2. Extensions to Resolver Data Structures . . . . . . . . . . 10
4.3. The Use of getsockname and getpeername Functions . . . . . 13 4.3. The Use of getsockname and getpeername Functions . . . . . 12
4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 13 4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 13
4.5. Verification of HIT Type . . . . . . . . . . . . . . . . . 14 4.5. Verification of HIT Type . . . . . . . . . . . . . . . . . 13
4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 15 4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 15
5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 16 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document defines the C-based sockets Application Programming This document defines the C-based sockets Application Programming
Interface (API) extensions for handling Host Identity Protocol (HIP)- Interface (API) extensions for handling Host Identity Protocol (HIP)-
based identifiers explicitly in HIP-aware applications. It is up to based identifiers explicitly in HIP-aware applications. It is up to
the applications, or high-level programming languages or libraries, the applications, or high-level programming languages or libraries,
to manage the identifiers. The extensions in this document are to manage the identifiers. The extensions in this document are
mainly related to the use case in which a DNS resolution step has mainly related to the use case in which a DNS resolution step has
occurred prior to the creation of a new socket, and assumes that the occurred prior to the creation of a new socket, and assumes that the
skipping to change at page 8, line 26 skipping to change at page 8, line 26
a new address family, AF_HIP. The AF_HIP and PF_HIP constants are a new address family, AF_HIP. The AF_HIP and PF_HIP constants are
aliases to each other. These definitions shall be defined as a aliases to each other. These definitions shall be defined as a
result of including <sys/socket.h>. result of including <sys/socket.h>.
When the socket() function is called with PF_HIP as the first When the socket() function is called with PF_HIP as the first
argument (domain), it attempts to create a socket for HIP argument (domain), it attempts to create a socket for HIP
communication. If HIP is not supported, socket() follows its default communication. If HIP is not supported, socket() follows its default
behaviour and returns -1 and sets errno to EAFNOSUPPORT. behaviour and returns -1 and sets errno to EAFNOSUPPORT.
Figure 2 shows the recommended implementation of the socket address Figure 2 shows the recommended implementation of the socket address
structure for HIP in POSIX.1.g format. structure for HIP in POSIX format.
#include <netinet/hip.h> #include <netinet/hip.h>
typedef struct in6_addr hip_hit_t; typedef struct in6_addr hip_hit_t;
struct sockaddr_hip { struct sockaddr_hip {
uint8_t ship_len; uint8_t ship_len;
sa_family_t ship_family; sa_family_t ship_family;
in_port_t ship_port; in_port_t ship_port;
uint32_t ship_flags; uint32_t ship_flags;
hip_hit_t ship_hit; hip_hit_t ship_hit;
}; };
Figure 2 Figure 2
uint8_t ship_len: This field is optional in POSIX.1.g (and 4.3BSD- uint8_t ship_len: This field defines the length of the structure.
RENO). The field defines the length of the structure.
Implementations that do not define this field typically embed the Implementations that do not define this field typically embed the
information in the following ship_family field. information in the following ship_family field.
sa_family_t ship_family: This mandatory field identifies this as a sa_family_t ship_family: This mandatory field identifies this as a
sockaddr_hip structure. It overlays the sa_family field of the sockaddr_hip structure. It overlays the sa_family field of the
sockaddr structure. Its value must be AF_HIP. sockaddr structure. Its value must be AF_HIP.
in_port_t ship_port: This mandatory field contains the transport in_port_t ship_port: This mandatory field contains the transport
protocol port number. It is handled in the same way as the sin_port protocol port number. It is handled in the same way as the sin_port
field of the sockaddr_in structure. The port number is stored in field of the sockaddr_in structure. The port number is stored in
skipping to change at page 10, line 34 skipping to change at page 10, line 33
an appropriate error type when the system failed to deliver the an appropriate error type when the system failed to deliver the
packet over a HIP-based data channel. The semantics of using the packet over a HIP-based data channel. The semantics of using the
HIP_ENDPOINT_ANY are the subject of further experimentation in the HIP_ENDPOINT_ANY are the subject of further experimentation in the
context of opportunistic mode. Such use may result in a data flow context of opportunistic mode. Such use may result in a data flow
either with or without HIP. either with or without HIP.
4.2. Extensions to Resolver Data Structures 4.2. Extensions to Resolver Data Structures
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 the applications can use to control the address type returned from the
getaddrinfo() function [RFC3493]. The getaddrinfo() function uses a getaddrinfo() function [RFC3493], [POSIX]. The getaddrinfo()
data structure called addrinfo in its "hints" and "res" argument function uses a data structure called addrinfo in its "hints" and
which is described in more detail in the next section. The addrinfo "res" argument which is described in more detail in the next section.
data structure is illustrated in Figure 3. 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_CANONNAME */ 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 */
skipping to change at page 18, line 34 skipping to change at page 18, line 12
folks, including Stephane Bortzmeyer, Chris Newman, Tony Finch, "der folks, including Stephane Bortzmeyer, Chris Newman, Tony Finch, "der
Mouse" and Keith Moore. Mouse" and Keith Moore.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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-09 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-11
(work in progress), July 2009. (work in progress), December 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.
[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
 End of changes. 13 change blocks. 
20 lines changed or deleted 19 lines changed or added

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