draft-ietf-hip-native-api-09.txt   draft-ietf-hip-native-api-10.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: March 14, 2010 Henderson Expires: June 13, 2010 T. Henderson
The Boeing Company The Boeing Company
September 10, 2009 December 10, 2009
Basic Socket Interface Extensions for Host Identity Protocol (HIP) Basic Socket Interface Extensions for Host Identity Protocol (HIP)
draft-ietf-hip-native-api-09 draft-ietf-hip-native-api-10
Abstract
This document defines extensions to the current sockets API for the
Host Identity Protocol (HIP). The extensions focus on the use of
public-key based identifiers discovered via DNS resolution, but
define also interfaces for manual bindings between HITs and locators.
With the extensions, the application can also support more relaxed
security models where the communication can be non-HIP based,
according to local policies. The extensions in this document are
experimental and provide basic tools for further experimentation with
policies.
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.
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
than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 March 14, 2010. This Internet-Draft will expire on June 13, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document defines extensions to the current sockets API for the This document may contain material from IETF Documents or IETF
Host Identity Protocol (HIP). The extensions focus on the use of Contributions published or made publicly available before November
public-key based identifiers discovered via DNS resolution, but 10, 2008. The person(s) controlling the copyright in some of this
define also interfaces for manual bindings between HITs and locators. material may not have granted the IETF Trust the right to allow
With the extensions, the application can also support more relaxed modifications of such material outside the IETF Standards Process.
security models where the communication can be non-HIP based, Without obtaining an adequate license from the person(s) controlling
according to local policies. The extensions in this document are the copyright in such materials, this document may not be modified
experimental and provide basic tools for further experimentation with outside the IETF Standards Process, and derivative works of it may
policies. not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Name Resolution Process . . . . . . . . . . . . . . . . . . . 5 3. Name Resolution Process . . . . . . . . . . . . . . . . . . . 6
3.1. Interaction with the Resolver . . . . . . . . . . . . . . 5 3.1. Interaction with the Resolver . . . . . . . . . . . . . . 6
3.2. Interaction without a Resolver . . . . . . . . . . . . . . 6 3.2. Interaction without a Resolver . . . . . . . . . . . . . . 7
4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 7 4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 8
4.1. Socket Family and Address Structure Extensions . . . . . . 7 4.1. Socket Family and Address Structure Extensions . . . . . . 8
4.2. Extensions to Resolver Data Structures . . . . . . . . . . 9 4.2. Extensions to Resolver Data Structures . . . . . . . . . . 10
4.3. The Use of getsockname and getpeername Functions . . . . . 12 4.3. The Use of getsockname and getpeername Functions . . . . . 13
4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 12 4.4. Selection of Source HIT Type . . . . . . . . . . . . . . . 13
4.5. Verification of HIT Type . . . . . . . . . . . . . . . . . 13 4.5. Verification of HIT Type . . . . . . . . . . . . . . . . . 14
4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 14 4.6. Explicit Handling of Locators . . . . . . . . . . . . . . 15
5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 15 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 HIP-based identifiers Interface (API) extensions for handling Host Identity Protocol (HIP)-
explicitly in HIP-aware applications. It is up to the applications, based identifiers explicitly in HIP-aware applications. It is up to
or high-level programming languages or libraries, to manage the the applications, or high-level programming languages or libraries,
identifiers. The extensions in this document are mainly related to to manage the identifiers. The extensions in this document are
the use case in which a DNS resolution step has occurred prior to the mainly related to the use case in which a DNS resolution step has
creation of a new socket, and assumes that the system has cached or occurred prior to the creation of a new socket, and assumes that the
is otherwise able to resolve identifiers to locators (IP addresses). system has cached or is otherwise able to resolve identifiers to
The DNS extensions for HIP are described in [RFC5205]. The locators (IP addresses). The DNS extensions for HIP are described in
extensions also cover the case in which an application may want to [RFC5205]. The extensions also cover the case in which an
explicitly provide suggested locators with the identifiers, including application may want to explicitly provide suggested locators with
supporting the opportunistic case in which the system does not know the identifiers, including supporting the opportunistic case in which
the peer host identity. 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 an stack. SHIM6 [RFC5533] is another protocol based on an identity-
identity-locator split. The APIs specified in this document are locator split. The APIs specified in this document are specific to
specific to HIP, but have been designed as much as possible so as not HIP, but have been designed as much as possible so as not to preclude
to preclude its use with other protocols. The use of these APIs with its use with other protocols. The use of these APIs with other
other protocols is, nevertheless, for further study. protocols is, nevertheless, for further study.
The APIs in this document are based on IPv6 addresses with the ORCHID The APIs in this document are based on HITs that are defined as IPv6
prefix [RFC4843]. ORCHIDs are derived from Host Identifiers using a addresses with the Overlay Routable Cryptographic Host Identifiers
hash and fitting the result into an IPv6 address. Such addresses are (ORCHID) prefix [RFC4843]. ORCHIDs are derived from Host Identifiers
called Host Identity Tags (HITs) and they can be distinguished from using a hash and fitting the result into an IPv6 address. Such
other IPv6 addresses via the ORCHID prefix. addresses are called Host Identity Tags (HITs) and they can be
distinguished from other IPv6 addresses via the ORCHID prefix. Note
that ORCHIDs are presently an experimental allocation by IANA. If
the ORCHID allocation were to expire and HIT generation were to use a
different prefix in the future, most users of the API would not be
impacted, unless they explicitly checked the ORCHID prefix on
returned HITs. Users who check (for consistency) that HITs have a
valid ORCHID prefix must monitor the IANA allocation for ORCHIDs and
adapt their software in case the ORCHID allocation were to be removed
at a future date.
Applications can observe the HIP layer and its identifiers in the Applications can observe the HIP layer and its identifiers in the
networking stacks with varying degrees of visibility. [RFC5338] networking stacks with varying degrees of visibility. [RFC5338]
discusses the lowest levels of visibility in which applications are discusses the lowest levels of visibility in which applications are
completely unaware of the underlying HIP layer. Such HIP-unaware completely unaware of the underlying HIP layer. Such HIP-unaware
applications in some circumstances use HIP-based identifiers, such as applications in some circumstances use HIP-based identifiers, such as
LSIs or HITs, instead of IPv4 or IPv6 addresses and cannot observe Local Scope Identifiers (LSIs) or HITs, instead of IPv4 or IPv6
the identifier-locator bindings. addresses and cannot observe the identifier-locator bindings.
This document specifies extensions to [RFC3493] to define a new This document specifies extensions to [RFC3493] to define a new
socket address family, AF_HIP. Similarly to other address families, socket address family, AF_HIP. Similarly to other address families,
AF_HIP can be used as an alias for PF_HIP. The extensions also AF_HIP can be used as an alias for PF_HIP. The extensions also
describe a new socket address structure for sockets using HITs describe a new socket address structure for sockets using HITs
explicitly and describe how the socket calls in [RFC3493] are adapted explicitly and describe how the socket calls in [RFC3493] are adapted
or extended as a result. or extended as a result.
Some applications may accept incoming communications from any Some applications may accept incoming communications from any
identifier. Other applications may initiate outgoing communications identifier. Other applications may initiate outgoing communications
without the knowledge of the peer identifier in Opportunistic Mode without the knowledge of the peer identifier in Opportunistic Mode
(section 4.1.6 in [RFC5201]) by just relying on a peer locator. This (section 4.1.6 in [RFC5201]) by just relying on a peer locator. This
document describes how to address both situations using "wildcards" document describes how to address both situations using "wildcards"
as described in Section 4.1.1. as described in Section 4.1.1.
There are two related API documents. Multihoming and explicit This document references one additional API document that handles
locator-handling related APIs are defined in multihoming and explicit-locator handling, defined in
[I-D.ietf-shim6-multihome-shim-api]. IPsec-related policy attributes [I-D.ietf-shim6-multihome-shim-api]. Most of the extensions defined
and channel binding APIs are defined in [I-D.ietf-btns-c-api]. Most in this document can be used independently of the above document.
of the extensions defined in this document can be used independently
of the two mentioned API documents.
The identity-locator split introduced by HIP introduces some policy The identity-locator split introduced by HIP introduces some policy
related challenges with datagram oriented sockets, opportunistic related challenges with datagram oriented sockets, opportunistic
mode, and manual bindings between HITs and locators. The extensions mode, and manual bindings between HITs and locators. The extensions
in this document are of an experimental nature and provide basic in this document are of an experimental nature and provide basic
tools for experimenting with policies. Policy related issues are tools for experimenting with policies. Policy related issues are
left for further experimentation. left for further experimentation.
To recap, the extensions in this document have three goals. The To recap, the extensions in this document have three goals. The
first goal is to allow HIP-aware applications to open sockets to first goal is to allow HIP-aware applications to open sockets to
other hosts based on the HITs alone, presuming that the underlying other hosts based on the HITs alone, presuming that the underlying
system can resolve the HITs to addresses used for initial contact. system can resolve the HITs to addresses used for initial contact.
The second goal is that applications can explicitly initiate The second goal is that applications can explicitly initiate
communications with unknown peer identifiers. The third goal is to communications with unknown peer identifiers. The third goal is to
illustrate how HIP-aware applications can use the SHIM API illustrate how HIP-aware applications can use the SHIM API
[I-D.ietf-shim6-multihome-shim-api] to manually map locators to HITs. [I-D.ietf-shim6-multihome-shim-api] to manually map locators to HITs.
This document was published as experimental because a number of its
normative references had experimental status. The success of this
experiment can be evaluated by a thorough implementation of the APIs
defined.
2. Terminology 2. Terminology
The terms used in this document are summarized in Table 1. The terms used in this document are summarized in Table 1.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| FQDN | Fully Qualified Domain Name |
| HIP | Host Identity Protocol | | HIP | Host Identity Protocol |
| HI | Host Identity |
| 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 |
| RR | Return Routability |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
Table 1 Table 1
3. Name Resolution Process 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.
skipping to change at page 7, line 37 skipping to change at page 8, line 37
#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 is optional in POSIX.1.g (and 4.3BSD-
RENO). The 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
skipping to change at page 10, line 27 skipping to change at page 11, line 27
}; };
Figure 3 Figure 3
An application resolving with the ai_family field set to AF_UNSPEC in An application resolving with the ai_family field set to AF_UNSPEC in
the hints argument may receive any kind of socket address structures, the hints argument may receive any kind of socket address structures,
including sockaddr_hip. When the application wants to receive only including sockaddr_hip. When the application wants to receive only
HITs contained in sockaddr_hip structures, it should set the HITs contained in sockaddr_hip structures, it should set the
ai_family field to AF_HIP. Otherwise, the resolver does not return ai_family field to AF_HIP. Otherwise, the resolver does not return
any sockaddr_hip structures. The resolver returns EAI_FAMILY when any sockaddr_hip structures. The resolver returns EAI_FAMILY when
AF_HIP is not supported. AF_HIP is requested but not supported.
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
skipping to change at page 16, line 31 skipping to change at page 17, line 31
+-----------------+-----------------------+ +-----------------+-----------------------+
Table 4 Table 4
6. IANA Considerations 6. IANA Considerations
No IANA considerations. No IANA considerations.
7. Security Considerations 7. Security Considerations
This document describes an API for HIP and therefore depends on the
mechanisms defined in the HIP protocol suite. Security concerns
associated with HIP itself are specified in [RFC4423], [RFC4843],
[RFC5201], [RFC5205], and [RFC5338].
The HIP_ENDPOINT_ANY constant can be used to accept incoming or The HIP_ENDPOINT_ANY constant can be used to accept incoming or
create outgoing data flows without HIP. The application should use create outgoing data flows without HIP. The application should use
the sockaddr_is_srcaddr() function to validate the type of the 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 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. The use of the HIP_HIT_ANY_* constants is recommended in
security-critical applications and systems. security-critical applications and systems.
It should be noted that the wildcards described in this document are It should be noted that the wildcards described in this document are
not suitable for identifying end-hosts. Instead, applications should not suitable for identifying end-hosts. Instead, applications should
use getsockname() and getpeername() as described in Section 4.3 to use getsockname() and getpeername() as described in Section 4.3 to
skipping to change at page 17, line 23 skipping to change at page 18, line 27
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, Tobias Heer, Stefan Gotz and Gonzalo Camarillo have Jeff Ahrenholz, Tobias Heer, Stefan Gotz and Gonzalo Camarillo have
provided valuable ideas and feedback. Thanks also for the APPS area provided valuable ideas and feedback. Thanks also for the APPS area
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. Normative References 10. References
[I-D.ietf-btns-c-api] 10.1. Normative References
Richardson, M., Williams, N., Komu, M., and S. Tarkoma,
"C-Bindings for IPsec Application Programming Interfaces",
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-09 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-09
(work in progress), July 2009. (work in progress), July 2009.
[I-D.ietf-shim6-proto]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
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.
[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.
skipping to change at page 18, line 24 skipping to change at page 19, line 22
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205, (HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008. April 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, Identity Protocol with Legacy Applications", RFC 5338,
September 2008. September 2008.
10.2. Informative References
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Helsinki Helsinki
Finland Finland
Phone: +358503841531 Phone: +358503841531
Fax: +35896949768 Fax: +35896949768
 End of changes. 25 change blocks. 
85 lines changed or deleted 116 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/