draft-ietf-hip-native-api-03.txt   draft-ietf-hip-native-api-04.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: Informational Technology Intended status: Experimental Technology
Expires: May 22, 2008 November 19, 2007 Expires: August 28, 2008 Henderson
The Boeing Company
February 25, 2008
Native Application Programming Interfaces (APIs) for Host Identity Basic Socket Interface Extensions for Host Identity Protocol (HIP)
Protocol (HIP) draft-ietf-hip-native-api-04
draft-ietf-hip-native-api-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into be created, except to publish it as an RFC and to translate it into
languages other than English. languages other than English.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
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 May 22, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines extensions to the current sockets API for Host This document defines extensions to the current sockets API for Host
Identity Protocol (HIP). The extensions focus on the initial Identity Protocol (HIP). The extensions focus on the use of public-
discovery of public-key based identifiers. Using the extensions, the key based identifiers discovered via DNS resolution, but define also
application can verify that the identifier is a Host Identity Tag interfaces for manual bindings between HITs and locators. With the
(HIT) and it can require the system resolver to return only HITs from extensions, the application can also support more relaxed security
DNS. The application can also to explicitly allow more relaxed models where the communication can be non-HIP based, according to
security models where the communication can be non-HIP based in the local policies. The extensions in document are experimental and
absence of a peer identifiers, or that the application allows peer provide basic tools for futher experimentation with policies.
identity to be discovered after initial contact directly with the
peer.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. API Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Namespace Model . . . . . . . . . . . . . . . . . . . . . 4 3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5
3.2. Interaction with the Resolver . . . . . . . . . . . . . . 5 3.2. Interaction without a Resolver . . . . . . . . . . . . . . 5
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 6 4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 6
4.1. Socket Family and Address Structure Extensions . . . . . . 6 4.1. Socket Family and Address Structure Extensions . . . . . . 6
4.2. Resolver Extensions . . . . . . . . . . . . . . . . . . . 8 4.2. Extensions to Resolver Data Structures . . . . . . . . . . 8
4.3. Manual Handling of Locators . . . . . . . . . . . . . . . 10 4.2.1. Resolver Usage . . . . . . . . . . . . . . . . . . . . 9
4.3. The Use of getsockname and getpeername Functions . . . . . 10
5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 10 4.4. Validating HITs . . . . . . . . . . . . . . . . . . . . . 10
4.5. Source HIT Selection by the System . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Terminology 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
The terms used in this document are summarized in Table 1. 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
+---------+---------------------------------------------------------+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
| Term | Explanation | Intellectual Property and Copyright Statements . . . . . . . . . . 18
+---------+---------------------------------------------------------+
| HIP | Host Identity Protocol |
| HIT | Host Identity Tag, a 100-bit hash of a public key with |
| | a 28 bit prefix |
| LSI | Local Scope Identifier, a local, 32-bit descriptor for |
| | a given public key. |
| Locator | Routable IPv4 or IPv6 address used at the lower layers |
+---------+---------------------------------------------------------+
Table 1 1. Introduction
2. Introduction This document defines C-based sockets Application Programming
Interface (API) extensions for handling HIP-based identifiers
explicitly in HIP-aware applications. It is up to the applications,
or high-level programming languages or libraries, to manage the
identifiers. The extensions in this document are 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 system has cached or
is otherwise able to resolve identifiers to locators (IP addresses).
The DNS extensions for HIP are described in [I-D.ietf-hip-dns]. The
extensions also cover the case in which an application may want to
explicitly provide suggested locators with the identifiers, including
supporting the opportunistic case in which the system does not know
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 Application Programming identity-locator split. Note that the APIs specified in this
Interfaces (APIs) specified in this document are specific to HIP. document are specific to HIP. However, the APIs here have been
However, the APIs here have been designed keeping generality in mind designed as much as possible so as not to preclude its use with other
as much as possible so as not to preclude its use with other
protocols. The use of these APIs with other protocols is, protocols. The use of these APIs with other protocols is,
nevertheless, for further study. nevertheless, for further study.
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. networking stacks with varying degrees of visibility.
[I-D.henderson-hip-applications] discusses the lowest levels of [I-D.ietf-hip-applications] discusses the lowest levels of visibility
visibility in which applications are completely unaware of the in which applications are completely unaware of the underlying HIP
underlying HIP layer. Such HIP-unaware applications use HIP-based layer. Such HIP-unaware applications use HIP-based identifiers, such
identifiers, such as LSIs or HITs, instead of IPv4 or IPv6 addresses as LSIs or HITs, instead of IPv4 or IPv6 addresses and cannot observe
and cannot observe the identifier-locator bindings. the identifier-locator bindings.
This document defines C-based sockets API extensions for handling
HIP-based identifiers explicitly in HIP-aware applications. It is up
to the applications, or a high-level programming languages or
libraries, to manage the identifiers. The extensions in this
document are mainly related to the initial discovery of the
identifiers, i.e., DNS resolution step.
The API extensions introduce a new address family, AF_HIP, and a new This document specifies extensions to [RFC3493] to define a new
socket address structure for sockets using Host Identity Tags (HITs) socket address family, AF_HIP. The macro PF_HIP is used as an alias
explicitly. PF_HIP is used as an alias for AF_HIP in this document for AF_HIP in this document because the distinction between PF and AF
because the distinction between PF and AF has been lost in the has been lost in practice. The extensions also describe a new socket
practice. address structure for sockets using Host Identity Tags (HITs)
explicitly and describe how the socket calls in [RFC3493] are adapted
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 knowledge of the peer identifier in Opportunistic Mode without the knowledge of the peer identifier in Opportunistic Mode
[I-D.ietf-hip-base] by just relying on a peer locator. This document [I-D.ietf-hip-base] by just relying on a peer locator. This document
describes how to address both situations using "wildcards" as describes how to address both situations using "wildcards" as
described later in this document. 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]. The and channel bindings APIs are defined in [I-D.ietf-btns-c-api]. Most
extensions defined in this document can be used independently of the of the extensions defined in this document can be used independently
two mentioned related API documents. of the two mentioned related API documents.
To recap, the extensions in this document have two goals. The first The identity-locator split introduced by HIP introduces some policy
goal is to allow HIP-aware applications to resolve HITs explicitly. related challenges with datagram oriented sockets, opportunistic
The second goal is that applications can explicitly accept mode, and manual bindings between HITs and locators. The extensions
communications with unknown peer identifiers. in this document are of experimental nature and provide basic tools
for experimenting with policies. Policy related issues are left for
further experimentation.
3. Design Model To recap, the extensions in this document have three goals. The
first goal is to allow HIP-aware applications to open sockets to
other hosts based on the HITs alone, presuming that the underlying
system can resolve the HITs to addresses used for initial contact.
The second goal is that applications can explicitly initiate
communications with unknown peer identifiers. The third goal is to
define how HIP-aware applications may provide suggested initial
contact addresses along with the HITs.
In this section, the native HIP APIs is described from a design point 2. Terminology
of view. We first describe the namespace model and conclude the
discussion with a description of the resolver model.
3.1. Namespace Model The terms used in this document are summarized in Table 1.
The namespace model is shown in Table 2 from HIP point of view. The +---------+---------------------------------------------------------+
namespace identifiers are described in this section. | Term | Explanation |
+---------+---------------------------------------------------------+
| HIP | Host Identity Protocol |
| HIT | Host Identity Tag, a 100-bit hash of a public key with |
| | a 28 bit prefix |
| LSI | Local Scope Identifier, a local, 32-bit descriptor for |
| | a given public key. |
| Locator | Routable IPv4 or IPv6 address used at the lower layers |
+---------+---------------------------------------------------------+
+-------------------+---------------------------+ Table 1
| Layer | Identifier |
+-------------------+---------------------------+
| User Interface | Relative hostname or FQDN |
| Application Layer | HIT, port and protocol |
| Transport Layer | HIT, port |
| HIP Layer | HIT or HI |
| Network Layer | Locator |
+-------------------+---------------------------+
Table 2 3. API Overview
User interfaces input human-readable names and translate them to This section provides an overview of how the API can be used. First,
machine-readable names. In native APIs for HIP, the machine readable the case in which a resolver is involved in name resolution is
names are HITs. The HITs are present at the application layer, and described, and then the case in which no resolver is involved is
transport-layer pseudo checksums are based on HITs. The HIP layer described.
transforms the HITs to locators for the network layer and vice versa.
3.2. 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 (step a.) to resolve an FQDN (step The application calls the resolver in step a to resolve an FQDN step
b.). The DNS server responds with a list of HITs and a set of b. The DNS server responds with a list of HITs and a set of locators
locators (step c.). Optionally (in step d.), the resolver caches the step c. Optionally in step d, the resolver caches the HIT to locator
HIT to locator mapping to the HIP module. The resolver returns the mapping to the HIP module. The resolver returns the HITs to the
HITs to the application in step e. Finally, the application selects application step e. Finally, the application selects one HIT and
one HIT and uses it in a socket call such as connect() in step e. uses it in a socket call such as connect() in step f.
+----------+ +----------+
| | | |
| DNS | | DNS |
| | | |
+----------+ +----------+
^ | ^ |
b. <FQDN> | | c. <HITs + locators b. <FQDN> | | c. <HITs + locators
| v = HITs+locs> | v = HITs+locs>
+-------------+ a. getaddrinfo(<FQDN>) +----------+ +-------------+ a. getaddrinfo(<FQDN>) +----------+
skipping to change at page 5, line 51 skipping to change at page 5, line 47
| 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 DNS proxy.
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 the HIT with the locator(s). resolver associates implicitly the HIT with the locator(s) by e.g.
However, it is possible that an application operates directly with a communicating the HIT-to-IP mapping to the HIP daemon. However, it
peer HIT without interacting with the resolver. In such a case, the is possible that an application operates directly on a 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 as specified in [I-D.ietf-shim6-multihome-shim-api]. to an IP address using socket options as specified in
Both of these two approaches may be more prone to errors than the use [I-D.ietf-shim6-multihome-shim-api]. Full support for all of the
resolver with host names. Hence, HIP-aware applications should extensions defined in this draft requires shim socket options to be
prefer to use the resolver with host names. 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
The sockets API extensions define a new protocol family, PF_HIP, and The sockets API extensions define a new protocol family, PF_HIP, and
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. The use of the PF_HIP constant is mandatory with the each other. The use of the PF_HIP constant is mandatory with the
socket() function when application uses the native HIP APIs. The socket() function when 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 EPFNOSUPPORT in the to the socket() function. The system returns a positive integer
socket call when it does not support HIP. representing a socket descriptor when the system supports HIP.
Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT.
The application can also use the new PF_HIP family to detect HIP
support in the local host. Namely, the application creates a socket
by calling socket() function with the first argument (domain) as
PF_HIP. The system returns a positive integer representing a socket
descriptor when the system supports HIP. Otherwise, the system
returns -1 and sets errno to EAFNOSUPPORT.
A HIT is contained in a sockaddr_hip structure, which is shown in A HIT is contained in a sockaddr_hip structure, which is shown in
Figure 2. The family of the socket, ship_family, is set to PF_HIP. Figure 2 in 4.4BSD format. The family of the socket, ship_family, is
The port number ship_port is two octets and the sins_hit is four set to PF_HIP. The port number ship_port is two octets and the
octets. The HIT value is an IPv6 address and it is stored in network ship_hit is 16 octets.
byte order.
#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 {
uint8_t ship_len; uint8_t ship_len;
uint8_t ship_family; uint8_t ship_family;
uint16_t ship_port; uint16_t ship_port;
uint64_t ship_flags; uint64_t ship_flags;
skipping to change at page 7, line 19 skipping to change at page 7, line 4
struct sockaddr_hip { struct sockaddr_hip {
uint8_t ship_len; uint8_t ship_len;
uint8_t ship_family; uint8_t ship_family;
uint16_t ship_port; uint16_t ship_port;
uint64_t ship_flags; uint64_t ship_flags;
hip_hit_t ship_hit; hip_hit_t ship_hit;
uint8_t reserved[16]; uint8_t reserved[16];
} }
Figure 2 Figure 2
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 wildcard macros to set
a value directly into the ship_hit field. The macros are a value directly into the ship_hit field. The macros are
HIP_HIT_ANY, HIP_HIT_ANY_PUB and HIP_HIT_ANY_ANON. They denote a HIT HIP_HIT_ANY, HIP_HIT_ANY_PUB, HIP_HIT_ANY_TMP and HIP_ADDR_ANY. The
value associated with a wildcard HIT of any, public, or anonymous first three equal to a HIT value associated with a wildcard HIT of
type. The HIP_HIT_ANY means HIP_HIT_ANY_PUB or HIP_HIT_ANY_ANON. any, public, or anonymous type. The fourth macro, HIP_ADDR_ANY,
The anonymous identifiers refer to the use anonymous identifiers as denotes both HIP_HIT_ANY or any IPv4 or IPv6 address. The
HIP_HIT_ANY equals to HIP_HIT_ANY_PUB or HIP_HIT_ANY_TMP. The
anonymous identifiers refer to the use anonymous identifiers as
specified in [RFC4423]. The system may designate anonymous specified in [RFC4423]. The system may designate anonymous
identifiers as meta data associated with a HIT regarding whether it identifiers as meta data associated with a HIT depending on whether
has been published or not, but that from the HIP protocol it has been published or not. However, there is no difference in the
perspective, there is no difference in the classes of HITs. classes of HITs from the HIP protocol perspective,
The application can use the macro HIP_IS_IPV6_ADDR_ANON_HIT to verify
whether a HIT is anonymous or public. The macro inputs a pointer to
a hip_hit_t structure and returns an integer (int) set to one when
the corresponding HIT is anonymous and zero when it is public. The
macro returns -1 when the anonymity status is not available.
The application can use the HIP_HIT_ macros to accept incoming The application can use the HIP_HIT_ANY_* and HIP_ADDR_ANY macros to
communications to all of the HITs of the local host. Incoming accept incoming communications to all of the HITs of the local host.
communications refers here to the functions such as bind(), Incoming communications refers here to the functions such as bind(),
recvfrom() and recvmsg(). The HIP_HIT_ macros correspond to the recvfrom() and recvmsg(). The HIP_HIT_* macros are similar to the
sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT, but they are sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT, but they are
applicable at the HIP layer. After initial contact with the peer, applicable to HITs only. After initial contact with the peer, the
the local and peer HITs can be discovered using getsockname() and application can discover the local and peer HITs using getsockname()
getpeername() calls for connection oriented sockets. and getpeername() calls in the context of connection oriented
sockets. The difference between the use of the HIP_HIT_* and
HIP_ADDR_ANY macros here is that the former allows only HIP-based
communications but the latter also allows communications without HIP.
The application also uses the the HIP_HIT_ANY macro in ship_hit field The application also uses the HIP_HIT_ANY macro in ship_hit field to
to establish outgoing communications in Opportunistic mode establish outgoing communications in Opportunistic mode
[I-D.ietf-hip-base], when the application knows the remote peer [I-D.ietf-hip-base], i.e., when the application knows the remote peer
locator but not the HIT. Outgoing communications refers here to the locator but not the HIT. Outgoing communications refers here to the
use of functions such as connect(), sendto() and sendmsg(). After use of functions such as connect(), sendto() and sendmsg(). However,
initial contact with the peer, the application discovers local and the application must first associate the socket with at least one IP
peer HITs using getsockname() and getpeername() calls when it is address of the peer using SHIM_LOCLIST_PEER_PREF socket option.
using connection-oriented sockets.
The HIP_HIT_ANY_ macros also allow non-ORCHID based communications. The use of HIP_ADDR_ANY macro in the context of outgoing
To distinguish between ORCHID [RFC4843] and non-ORCHID-based communications is left for further experimentation. It could be used
communications in the case of the HIP_HIT_ANY_ macros, the for establishing a non-HIP based connectivity when HIP-based
application calls getsockname() and getpeername() to discover the connectivity was unsuccessful.
actual identifiers used for the communications and verifies orchid
prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a
pointer to an in6_addr structure and returns 1 when the address has
orchid prefix and 0 otherwise. Alternatively, the application can
set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow only ORCHID-
based communications.
Applications can also implement access control using the HITs. In Some applications rely on system level access control, either
such a case, the application can compare two HITs using memcmp() or implicit or explicit (such as accept_filter() function found on BSD-
similar function. It should be noticed that different connection based systems), but such discussion is out of scope. Other
applications implement access control themselves by using the HITs.
In such a case, the application can compare two HITs using memcmp()
or similar function. It should be noticed that different connection
attempts between the same two hosts can result in different HITs attempts between the same two hosts can result in different HITs
because a host is allowed to have multiple HITs. because a host is allowed to have multiple HITs.
4.2. Resolver Extensions 4.2. Extensions to Resolver Data Structures
The HIP APIs introduces a new addrinfo flag, AI_HIP, to be used by The HIP APIs introduce a new addrinfo flag, HIP_PREFER_ORCHID, to be
application to query for both HIT and locator information via the used by application to query for both HIT and locator information via
getaddrinfo() resolver function [RFC3493]. The getaddrinfo() the getaddrinfo() resolver function [RFC3493]. The getaddrinfo()
function uses a data structure used for both input to and output from function uses a data structure used for both input to and output from
the resolver. The data structure is illustrated in Figure 3. the resolver. The data structure is illustrated in Figure 3.
#include <netdb.h> #include <netdb.h>
struct addrinfo { struct addrinfo {
int ai_flags; /* e.g. AI_HIP */ int ai_flags; /* e.g. AI_EXTFLAGS */
int ai_family; /* e.g. PF_HIP */ int ai_family; /* e.g. PF_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 */
size_t ai_addrlen; /* size of *ai_addr */ size_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 */
}; };
Figure 3 Figure 3
The flag AI_HIP must be set in the ai_flags, or otherwise the Application must set both the flag AI_EXTFLAGS [RFC5014] in ai_flags
resolver does not return sockaddr_hip data structures. The resolver and HIP_PREFER_ORCHID in the ai_eflags, or otherwise the resolver
returns EAI_BADFLAGS when AI_HIP is not supported. The simultaneous does not return sockaddr_hip data structures. The resolver returns
use of both AI_HIP and AI_PASSIVE flags equals to the use HIP_HIT_ANY EAI_BADFLAGS when it does not support HIP_PREFER_ORCHID or
macro as described in section Section 4.1. Similarly, the use of AI_EXTFLAGS flags.
AI_PASSIVE_PUB and AI_PASSIVE_ANON flag equals to the use of
HIP_HIT_ANY_PUB and HIP_HIT_ANY_ANON.
The ai_family field is set to PF_HIP in the addrinfo structure when Application denotes its preference for public and anonymous types of
ai_addr points to a sockaddr_hip structure. 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
HIP_PREFER_PASSIVE_* flags produces a single sockaddr_hip structure
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 PF_HIP in the addrinfo
structure when ai_addr points to a sockaddr_hip structure.
When ai_protocol field is set to zero, the resolver also returns When ai_protocol field is set to zero, the resolver also returns
locators in sockaddr_in and sockaddr_in6 structures in addition to locators in sockaddr_in and sockaddr_in6 structures in addition to
sockaddr_hip structures. The resolver only returns sockaddr_hip sockaddr_hip structures. The resolver returns only sockaddr_hip
structures when ai_protocol field is set to IPPROTO_HIP or a structures when the application has set the ai_protocol field to
sockaddr_hip structure is given as the hint argument to the resolver. IPPROTO_HIP or a sockaddr_hip structure is given as the hint argument
to the resolver.
A HIP-aware application creates the sockaddr_hip structures manually 4.2.1. Resolver Usage
or obtains them from the resolver. The manual configuration is
described in [I-D.ietf-shim6-multihome-shim-api]. This document A HIP-aware application creates the sockaddr_hip structures
defines resolver extensions for getaddrinfo resolver [RFC3493]. explicitly or obtains them from the resolver. The explicit
configuration of locators is described in
[I-D.ietf-shim6-multihome-shim-api]. This document defines
"automated" resolver extensions for getaddrinfo() 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
skipping to change at page 9, line 48 skipping to change at page 9, line 44
Both the nodename and servname cannot be NULL. Both the nodename and servname cannot be NULL.
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 res argument with the free_addrinfo function.
The res argument contains a linked list of the resolved endpoints. The res argument contains a linked list of the resolved endpoints.
The linked list contains sockaddr_hip structures only when the input The linked list contains sockaddr_hip structures only when the input
argument has the AI_HIP flag set. The resolver inserts HITs before argument has the HIP_PREFER_ORCHID flag set in ai_eflags. The
any locators. resolver inserts HITs before any locators. When the
HIP_PREFER_ORCHID flag is set, the resolver does not return LSIs or
HITs encapsulated into sockaddr_in or sockaddr_in6 data structures as
described in [I-D.ietf-hip-applications].
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 to the HIP module. The HIP
module manages the multiple locators according to local policies of module manages the multiple locators according to system policies of
the host. the host. The multihoming document
[I-D.ietf-shim6-multihome-shim-api] describes how an application can
override system default policies.
4.3. Manual Handling of Locators It should be noticed that the application can configure the HIT
explicitly without setting the locator or the resolver can fail to
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
provide the mapping, it returns -1 in the called sockets API function
to the application and sets errno to EADDRNOTAVAIL.
4.3. The Use of getsockname and getpeername Functions
The application usually discovers the local or peer HITs from the
sockaddr_hip structures returned by getaddrinfo(). However, the
sockaddr_hip structure does not contain a HIT when the application
uses the HIP_HIT_ANY_* macros. In such a case, the application
discovers the local and peer HITs using the getsockname() and
getpeername() functions. The functions return sockadd_hip structures
when the family of the socket is PF_HIP.
4.4. Validating HITs
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 sockaddr_is_srcaddr() function operates in the same way as
inet6_is_srcaddr() function [RFC5014] which can be used to verify the
type of an address belonging to the localhost. The difference is
that sockaddr_is_srcaddr() function handles sockaddr_hip structures
in addition to sockaddr_in6, and possibly some other socket
structures in further extensions. The function has also 64 bit flags
instead of 32 bits. This new function handles the same flags as
defined in [RFC5014] in addition to some HIP-specific flags listed in
Table 2.
+-----------------------+-------------------------+
| Flag | Purpose |
+-----------------------+-------------------------+
| HIP_PREFER_ORCHID | The identifier is a HIT |
| HIP_PREFER_SRC_TMP | Anonymous HIT |
| HIP_PREFER_SRC_PUBLIC | Public HIT |
+-----------------------+-------------------------+
Table 2
4.5. Source HIT Selection by the System
Some applications initiate communications by specifying only the
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.
+-----------------+------------+-------+
| HIT Type | Precedence | Label |
+-----------------+------------+-------+
| Anonymous DSA | 110 | 5 |
| Anonymous RSA | 120 | 6 |
| Public DSA | 130 | 7 |
| Public RSA | 140 | 8 |
| [RFC3484] rules | 50-100 | 7 |
+-----------------+------------+-------+
Table 3
When application using a PF_HIP-based socket does not specify the
source identifier, the system selects the source identifier on the
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
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 presedence
value to denote that HITs have a higher precedence when operating on
PF_HIP-based sockets.
[RFC5014] specifies flags for the getaddrinfo resolver and socket
options for MobileIPv6. The resolver, operating under
HIP_PREFER_ORCHID flag, or the socket handler, operating on a PF_HIP-
based socket, may encounter such flags or options. In such a case
the resolver or socket handler should silenty ignore the flags or
options without returning an error. However, a HIP-aware application
may use the HIP-specific flags HIP_PREFER_ORCHID, HIP_PREFER_SRC_TMP
or HIP_PREFER_SRC_PUBLIC in getsockopt(), setsockopt(), getaddrinfo()
calls and in the anchillary data of datagram packets as specified in
[RFC5014]. The level of the socket options should be set to SOL_SHIM
[I-D.ietf-shim6-multihome-shim-api] and the option name should be
HIP_HIT_PREFERENCES.
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 PF_HIP as the domain argument. Second, the creates a socket with PF_HIP as the domain argument. Second, the
application binds the socket to a local or peer locator with the application may set locator information with one of the following
setsockopt function with either SHIM_LOC_LOCAL_PREF or shim socket options as defined in the multihoming extensions in
SHIM_LOC_PEER_PREF as the socket option name as defined in [I-D.ietf-shim6-multihome-shim-api]:
[I-D.ietf-shim6-multihome-shim-api]. Third, the application creates
a valid sockaddr_hip structure. Finally, the application associates
the socket also with the sockaddr_hip structure by calling some
socket-related function, such as connect or bind. The function
returns EINVALIDLOCATOR when the HIT is not reachable at the
specified locator.
It should be noticed that the application may just configure the HIT +-----------------------------+-----+-----+-----------------+-------+
manually without setting the locator. In this scenario, the | optname | get | set | description | dtype |
application relies on the system to map the HIT to an IP address. +-----------------------------+-----+-----+-----------------+-------+
When the system fails to provide the mapping, it returns | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 |
EADDRNOTAVAIL in the called sockets API function to the application | | | | preferred | |
and sets errno to indicate the error. | | | | 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:
An application that initiates a connection using a connection
oriented socket to a particular host at a known address or set of
addresses can call SHIM_LOCLIST_PEER socket option. The HIP module
uses the 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 permissable 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
mode, when the destination HIT is specified as a wildcard. This can
be accomplished by setting one or more destination addresses using
the SHIM_LOCLIST_PEER socket option as described above and then
calling connect() with the wildcard HIT. The connect() call returns
-1 and sets errno to EADDRNOTAVAIL when the application connected to
a wildcard without specifying any destination address.
Applications may also choose to associate local addresses with
sockets. The procedures specified in
[I-D.ietf-shim6-multihome-shim-api] are followed in this case.
5. Summary of New Definitions 5. Summary of New Definitions
Table 3 summarizes the new macro and structures defined in this Table 4 summarizes the new macro and structures defined in this
document. document.
+-----------------+---------------------------+ +-----------------+-----------------------------+
| Header | Definition | | Header | Definition |
+-----------------+---------------------------+ +-----------------+-----------------------------+
| <sys/socket.h> | PF_HIP | | <sys/socket.h> | PF_HIP |
| <sys/socket.h> | AF_HIP | | <sys/socket.h> | AF_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_ANON | | <netinet/hip.h> | HIP_HIT_ANY_TMP |
| <netinet/hip.h> | HIP_IS_IPV6_ADDR_ORCHID | | <netinet/hip.h> | HIP_ADDR_ANY |
| <netinet/hip.h> | HIP_IS_IPV6_ADDR_ANON_HIT | | <netinet/hip.h> | HIP_HIT_PREFERENCES |
| <netinet/hip.h> | HIP_FLAG_ONLY_ORCHID |
| <netdb.h> | AI_HIP |
| <netdb.h> | AI_PASSIVE_ANON |
| <netdb.h> | AI_PASSIVE_PUB |
| <netdb.h> | AI_HIP_NOLOCATORS |
| <netinet/hip.h> | hip_hit_t | | <netinet/hip.h> | hip_hit_t |
| <netdb.h> | HIP_PREFER_ORCHID |
| <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/in.h> | sockaddr_hip | | <netinet/in.h> | sockaddr_hip |
+-----------------+---------------------------+ | <netinet/in.h> | sockaddr_is_srcaddr |
+-----------------+-----------------------------+
Table 3 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.
8. Acknowledgements 8. Acknowledgements
Jukka Ylitalo and Pekka Nikander have contributed many ideas, time Jukka Ylitalo and Pekka Nikander have contributed many ideas, time
and effort to the native HIP APIs. Thomas Henderson, Kristian and effort to the native HIP APIs. Kristian Slavov, Julien Laganier,
Slavov, Julien Laganier, Jaakko Kangasharju, Mika Kousa, Jan Melen, Jaakko Kangasharju, Mika Kousa, Jan Melen, Andrew McGregor, Sasu
Andrew McGregor, Sasu Tarkoma, Lars Eggert, Joe Touch, Antti Tarkoma, Lars Eggert, Joe Touch, Antti Jaervinen, Anthony Joseph,
Jaervinen, Anthony Joseph, Teemu Koponen, Jari Arkko, Ari Keraenen, Teemu Koponen, Jari Arkko, Ari Keraenen, Juha-Matti Tapio, Shinta
Juha-Matti Tapio, Shinta Sugimoto, Philip Matthews, Jan Melen and Sugimoto, Philip Matthews, Jan Melen and Gonzalo Camarillo have also
Gonzalo Camarillo have also provided valuable ideas or feedback. provided valuable ideas or feedback. Thanks for the APPS area folks,
Thanks for the APPS area folks, Stephane Bortzmeyer, Chris Newman, Stephane Bortzmeyer, Chris Newman, Tony Finch, "der Mouse" and Keith
Tony Finch, "der Mouse" and Keith Moore for comments. Moore for comments.
9. Normative References 9. Normative References
[I-D.henderson-hip-applications]
Henderson, T. and P. Nikander, "Using HIP with Legacy
Applications", draft-henderson-hip-applications-03 (work
in progress), May 2006.
[I-D.ietf-btns-c-api] [I-D.ietf-btns-c-api]
Komu, M., "IPsec Application Programming Interfaces", Richardson, M., Williams, N., Komu, M., and S. Tarkoma,
draft-ietf-btns-c-api-01 (work in progress), July 2007. "IPsec Application Programming Interfaces",
draft-ietf-btns-c-api-03 (work in progress),
February 2008.
[I-D.ietf-hip-applications]
Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications",
draft-ietf-hip-applications-02 (work in progress),
November 2007.
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in "Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007. progress), October 2007.
[I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-09 (work in progress), April 2007.
[I-D.ietf-shim6-multihome-shim-api] [I-D.ietf-shim6-multihome-shim-api]
Komu, M., "Socket Application Program Interface (API) for Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-03 "Socket Application Program Interface (API) for
(work in progress), July 2007. Multihoming Shim", draft-ietf-shim6-multihome-shim-api-05
(work in progress), February 2008.
[I-D.ietf-shim6-proto] [I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work
in progress), November 2007. in progress), February 2008.
[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.
Author's Address [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsaenneidonkuja 4 Metsaenneidonkuja 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
The Boeing Company
P.O. Box 3707
Seattle, WA
USA
Email: thomas.r.henderson@boeing.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 77 change blocks. 
244 lines changed or deleted 452 lines changed or added

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