draft-ietf-hip-nat-traversal-02.txt   draft-ietf-hip-nat-traversal-03.txt 
HIP Working Group M. Komu, Ed. HIP Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Experimental S. Schuetz Intended status: Experimental T. Henderson
Expires: January 7, 2008 M. Stiemerling Expires: August 28, 2008 The Boeing Company
NEC P. Matthews
July 6, 2007 Avaya
H. Tschofenig
Nokia Siemens Networks
A. Keraenen
J. Melen
Ericsson Research Nomadiclab
M. Bagnulo
Huawei Lab at UC3M
February 25, 2008
HIP Extensions for the Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators and
draft-ietf-hip-nat-traversal-02 Firewalls
draft-ietf-hip-nat-traversal-03.txt
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.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 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
The Host Identity Protocol (HIP) provides a new namespace that can be The Host Identity Protocol (HIP) provides a new namespace that can be
used for uniquely identifying hosts in public and also in private used for uniquely identifying hosts. Existing HIP experimental
address realms. Usually, HIP control and data traffic cannot specifications do not specify protocol operations across Network
traverse Network Address Translators (NATs), that hinders general Address Translators (NATs).
deployment. This document specifies NAT traversal extensions for
HIP. As HIP is located between network and transport layer, the This document specifies NAT traversal extensions for HIP. The HIP
extensions also provide general-purpose NAT traversal support for all shim layer is located between the network and transport layer, the
high-layer networking applications that run over HIP. The basic extensions can also provide a more general-purpose NAT traversal
design concepts for these extensions have been adopted from the support for higher-layer networking applications. The extensions are
Interactive Connectivity Establishment (ICE) protocol to HIP. Using based on the use of the The Interactive Connectivity Establishment
the specified extensions, two HIP-capable hosts are able to (ICE) methodology to discover a working path between two end-hosts.
communicate with each other even when they are in different private Using the specified extensions, two HIP-capable hosts are able to
address realms. communicate with each other even when both nodes are behind NATs or
firewalls.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
3.1. Port Number Selection . . . . . . . . . . . . . . . . . . 6 3.1. Relay Registration and NAT Detection . . . . . . . . . . . 7
3.2. Relay Registration and NAT Detection . . . . . . . . . . . 6 3.2. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9
3.3. Base Exchange via Relay . . . . . . . . . . . . . . . . . 8 4. Connectivity Tests . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Base Exchange without a Relay . . . . . . . . . . . . . . 10 4.1. NAT Transformation Negotiation . . . . . . . . . . . . . . 11
3.5. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 11 4.2. ICE Procedure . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Selecting an Address Pair . . . . . . . . . . . . . . . . 13 4.3. NAT Keep-alives . . . . . . . . . . . . . . . . . . . . . 12
3.7. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 13
3.9. Closing of HIP Associations . . . . . . . . . . . . . . . 16 5.2. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 13
3.10. Communication with HIP Hosts without NAT Traversal 5.3. Relay and Registration Parameters . . . . . . . . . . . . 14
Support . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 14
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 17 5.6. Registration Types . . . . . . . . . . . . . . . . . . . . 16
4.2. Control Channel Keep-Alives . . . . . . . . . . . . . . . 18 5.7. HIP ESP Data Packet Formats . . . . . . . . . . . . . . . 17
4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 19 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 17
4.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 18
4.6. Registration Types . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4.7. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 21 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.8. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 21 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 18
5. Firewall Traversal . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 Appendix A. Firewall Traversal . . . . . . . . . . . . . . . . . 21
6.3. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Base Exchange without ICE Connectivity Checks . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 Appendix C. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 22
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix D. Base Exchange through a Rendezvous Server . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix E. Document Revision History . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 26
Appendix A. Differences to ICE . . . . . . . . . . . . . . . . . 28
Appendix B. Document Revision History . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Terminology 1. Introduction
In general, this document borrows the terminology from HIP [I-D.ietf-hip-base] is defined as a protocol that runs directly
[I-D.ietf-hip-base] and [RFC4423]. Additional terms are defined in over IPv4 or IPv6. This approach is known to have problems
the table below." These draft e.g. define "Initiator" and traversing NATs. Several different types of NATs exist, see
"Responder" [RFC2663]. This document describes HIP extensions for the traversal
of both Network Address Translator (NAT) and Network Address and Port
Translator (NAPT) middleboxes. Additionally, it covers firewalls to
a certain extend (see Appendix A for a more detailed discussion).
The document generally uses the term NAT to refer to these types of
middleboxes. A detailed description of HIP problems with traversing
legacy middleboxes is documented in [I-D.irtf-hiprg-nat].
+---------------------+---------------------------------------------+ NAT devices do not operate consistently even though a recommended
| Term | Explanation | behavior is described in [RFC4787]. The HIP protocol extensions in
+---------------------+---------------------------------------------+ this document make as few assumptions as possible about the behavior
| Rendezvous server | A host that forwards I1 packets to the | of the NAT devices so that NAT traversal will work even with legacy
| | Responder | NAT devices. The purpose of these extensions is to allow two HIP-
| HIP Relay | A host that forwards all HIP control | enabled hosts to communicate with each other even if one or both
| | packets between an Initiator and Responder | communicating hosts are in private address realms. With some legacy
| ESP Relay | A host that forwards ESP traffic between | NAT devices, utilizing the shortest path between two end hosts
| | two HIP-enabled hosts | located behind NATs is not possible without relaying the traffic
| Locator | A routable IPv4 or IPv6 address | through a relay, such as a TURN server [I-D.ietf-behave-p2p-state].
| Transport locator | Transport layer port and the corresponding | As a consequence, the TURN server increases the roundtrip delay and
| | IPv4/v6 address | may become a point of network congestion. With the extensions
| Unreflexive locator | An IPv4 or IPv6 address of a network | described in this document, hosts try to avoid the use of such a
| | interface of a host | relay when possible.
| Relay reflexive | A translated transport locator of a host as |
| transport locator | observed by a relay |
| Peer reflexive | A translated transport locator of a host as |
| transport locator | observed by its peer |
| Leased transport | Transport locator of an ESP relay |
| locator | |
+---------------------+---------------------------------------------+
Table 1: Terminology A distinction must be made between a HIP rendezvous server (defined
in [I-D.ietf-hip-rvs]) and a HIP Relay, defined herein. HIP
rendezvous servers solve initial contact and mobility related
problems in networks without NATs. HIP Relay solve the same
problems, in addition to NAT traversal problems. HIP Relay servers
can be used both in NATted and non-NATted networks.
2. Introduction Both rendezvous and relay services forward HIP control packets, but
the main difference is that the rendezvous service forwards only the
initial I1 packet of the base exchange while all other HIP control
packets are sent directly between the communicating hosts. In
contrast, the relay service relays all HIP control packets because
p2p-unfriendly NAT devices drop the packets otherwise
[I-D.ietf-behave-p2p-state]. The peers use the control channel to
communicate their current locators to each other to find a direct
path for carrying ESP encapsulated data traffic. A direct path
between the hosts enables efficient delivery of data traffic without
relaying of ESP packets through an intermediary TURN server. The
direct path is searched using connectivity tests.
The Host Identity Protocol (HIP) describes a new communication The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice].
mechanism for Internet hosts [RFC4423]. It introduces a new
namespace and protocol layer between the network and transport layers
that decouples the identifier and locator roles to support mobility
and multihoming in the Internet architecture. HIP also secures
application layer communications using IPsec ESP [I-D.ietf-hip-esp].
The HIP protocol [I-D.ietf-hip-base] cannot operate across legacy NAT [I-D.ietf-mmusic-ice] describes ICE as follows:
middleboxes as described in [I-D.irtf-hiprg-nat]. This document
specifies mechanisms that allow HIP to traverse through such NAT
middleboxes that are neither HIP-aware nor ESP-aware, without manual
configuration of the NAT middleboxes.
HIP introduces a new namespace for hosts that decouples the identity "The Interactive Connectivity Establishment (ICE) methodology is a
of a host from its location [RFC4423]. The namespace consists of technique for NAT traversal for UDP-based media streams (though
Host Identifiers which are public keys. The hosts create the ICE can be extended to handle other transport protocols, such as
corresponding private keys by themselves which makes identity theft TCP) established by the offer/answer model. ICE is an extension
more difficult. to the offer/answer model, and works by including a multiplicity
of IP addresses and ports in SDP offers and answers, which are
then tested for connectivity by peer-to-peer connectivity checks.
The IP addresses and ports included in the SDP and the
connectivity checks are performed using the revised STUN
specification [I-D.ietf-behave-rfc3489bis], now renamed to Session
Traversal Utilities for NAT."
The new namespace of HIP has some additional benefits when the ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP
extensions defined in this document are used. First, it is possible protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip].
to address hosts behind a single NAT middlebox in a relatively simple
way. The NAT middlebox translates the locators, but the Host
Identifiers remain the same and can be used for uniquely identifying
a host inside the private address realm. Second, multiple services
on different hosts can share the same transport layer port number
behind a single legacy NAT. There is no multiplexing issue as long
as these hosts have different Host Identifiers and UDP encapsulation
is used for traversing the legacy NAT.
Several different types of NATs exist [RFC2663]. This document Two hosts communicate their peer address set (typically consisting of
describes HIP extensions for the traversal of both Network Address IP address and port number pairs) to each other in the HIP base
Translator (NAT) and Network Address and Port Translator (NAPT) exchange. They are then paired with the locally operational address
middleboxes. The document generally uses the term NAT to refer to of the other end point and prioritized according to some policy.
both types of middleboxes, unless it needs to distinguish between the These address sets are then tested sequentially based on the
two types. procedure specified in ICE. Both sides participate in the
connectivity tests. The tests also determine whether operational
address pairs and select the preferred address pair to be used for
subsequent communication.
Three basic scenarios exist for NAT traversal. In the first case, As a summary, the extensions in this document
only the Initiator of a HIP base exchange is located behind a NAT.
In the second case, only the Responder of a HIP base exchange is
located behind a NAT. The respective peer is assumed to be located
at a publicly reachable address in both cases. In the third case,
both peers are located behind (possible different) NATs. All of the
use cases are addressed in the draft in a unified method that has
been adopted from Interactive Connectivity Establishment (ICE)
protocol [I-D.ietf-mmusic-ice] and adapted to HIP.
Legacy NAT devices do not operate consistently although the behavior o illustrate how to encapsulate HIP packets in UDP
for new NAT devices has been unified in [RFC4787]. The HIP protocol
extensions in this document make as little assumptions as possible of
the behavior of the NAT devices so that NAT traversal will work even
with legacy NAT devices in the most general sense. The purpose of
the extensions is to allow two HIP-enabled hosts to communicate with
each other even if one or both communicating hosts are in private
address realms. With some legacy NAT devices, connecting two hosts
behind different address realms is impossible without relaying all
traffic through a third party host [I-D.ietf-behave-p2p-state]. As a
consequence, the relay host introduces additional hops between the
hosts and can become a point of network congestion. In the
extensions described in this document, the peers try to avoid the use
of a relay for data traffic and only make use of it when necessary.
Hosts that always get a public addresses can use the rendezvous o refer to the UDP encapsulation of IPsec ESP packets defined in
services as described in [I-D.ietf-hip-rvs]. Hosts that can be Section 2.1 of RFC 3948 [RFC3948]
located in private-address realms may use a transport-layer based
relay service as defined in this document. Both rendezvous and relay
services forward HIP control packets, but the main difference is that
the rendezvous service forwards only the initial I1 packet of the
base exchange while all other HIP control packets are sent directly
between the communicating hosts. In contrast, the relay service
relays all HIP control packets because p2p-unfriendly NAT devices
drop the packets otherwise [I-D.ietf-behave-p2p-state]. The peers
use the control channel to communicate their current locators to each
other to find a direct path for carrying ESP encapsulated data
traffic. A direct path between the hosts enables efficient delivery
of data traffic without relaying of ESP packets through an
intermediary ESP relay. The direct path is searched using
connectivity tests.
The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice]. o define how a node interacts with a HIP rendezvous server (defined
Two hosts communicate their transport locator (a port and an IP in [I-D.ietf-hip-rvs]) when middleboxes are present
address) to each other in a base exchange. The local locators are
paired with peer locators and the pairs are prioritized according to
their proximity. The locator pairs are tested sequentially in
priority order using return routability tests [I-D.ietf-hip-mm].
Both sides participate in the connectivity tests. The tests also
determine whether transport layer encapsulation is required or not.
As a result, the hosts either detect that no transport locator pairs
are working, or establish a number of working locator pairs and
select a single pair to be used for communication.
The same connectivity tests are also used in situations when a mobile o describe a methodology to determine operational address pairs
host moves to a different network. The mobile host communicates its between two end hosts based on ICE.
new location to the corresponding node through the relay server of
its peer and starts the connectivity tests. 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. HIP Across NATs This document borrows terminology from [I-D.ietf-hip-base],
[I-D.ietf-hip-mm], [RFC4423], [I-D.ietf-mmusic-ice], and
[I-D.ietf-behave-rfc3489bis]. Additionally, the following terms are
used:
This section describes NAT traversal between two HIP end-hosts. A Rendezvous server:
successful NAT traversal requires at least the Responder located in a
private address realm to register to a relay server. The use of the
relay is optional when the Responder is located in a public address
realm without rendezvous server.
The base exchange is relayed through the relay server. Next, the A host that forwards I1 packets to the Responder
hosts test the reachability between the different locators to
construct a direct route. When a direct route is not possible, the
hosts resort to ESP relays. When locators of a host change, the
hosts test reachability of locators again and select the "optimal"
locator. End-hosts can tear down HIP associations using the CLOSE
mechanism through the relay.
3.1. Port Number Selection HIP Relay:
This document defines only UDP encapsulation for HIP and ESP packets. A host that forwards all HIP control packets between an Initiator
Further extensions may define bindings for other transport protocols. and Responder
The RECOMMENDED transport protocol is UDP.
It is RECOMMENDED that an Initiator selects a random port number TURN server:
between the ephemeral port ranged 49152-65535 for initiating a base
exchange even for registration. However, the allocated port MUST be
maintained until all of the corresponding Host Associations are
closed. Alternatively, a host MAY also use a single fixed port for
initiating all outgoing connections.
A relay or a Responder without a relay MUST listen at transport port A server that forwards data traffic between two end-hosts
HIPPORT for incoming UDP-encapsulated HIP control packets.
3.2. Relay Registration and NAT Detection Locator:
HIP rendezvous servers are used in non-NATted environments and its A name that controls how the packet is routed through the network
use is described in [I-D.ietf-hip-rvs]. This section defines the and demultiplexed by the end host. It may include a concatenation
another types middleboxes, called HIP and ESP Relays, which are used of traditional network addresses such as an IPv6 address and end-
in NATted environments. to-end identifiers such as an ESP SPI. It may also include
transport port numbers or IPv6 Flow Labels as demultiplexing
context, or it may simply be a network address. [I-D.ietf-hip-mm]
"Address" is used in this document as a synonym for locator.
A HIP relay forwards UDP-encapsulated traffic, and in future Transport address:
extensions, a relay may also forward TCP-encapsulated traffic. A
single relay may forward only HIP control packets, ESP traffic or
both. A host acting as a Responder in a private address realm SHOULD
use a HIP relay for NAT traversal. It is RECOMMENDED that the
Responder uses also an ESP relay to guarantee successful NAT
traversal with p2p-unfriendly NAT devices.
A relay MUST NOT forward any packets to a host that has not Transport layer port and the corresponding IPv4/v6 address
successfully registered to the relay. The registration process
follows the generic registration extensions defined in Candidate:
[I-D.ietf-hip-registration]. The registration process is illustrated
in Figure 1. A transport address that has not been verified yet for
reachability using ICE
Host candidate:
An IPv4 or IPv6 address of a network interface of a host
Server reflexive transport candidate:
A translated transport address of a host as observed by a HIP
Relay or a STUN server
Peer reflexive transport candidate:
A translated transport address of a host as observed by its peer
Relayed transport candidate:
A transport address that exists on a TURN server. If a permission
exists, packets that arrive at this address are relayed towards
the TURN client.
3. Protocol Description
This section describes the normative behavior of the protocol
extension. Examples of packet exchanges are provided for
illustration purposes.
3.1. Relay Registration and NAT Detection
HIP rendezvous servers are used in non-NATted environments and their
use is described in [I-D.ietf-hip-rvs]. This section specifies a new
role for these rendezvous servers to act as HIP Relays. HIP Relays
forward HIP control packets between the Initiator and the Responder.
TURN servers [I-D.ietf-behave-turn] are used for relaying ESP
traffic. A host SHOULD register to a TURN server before registering
to a HIP Relay to guarantee that the host can accept ESP traffic
immediately after HIP Relay registration.
A HIP relay forwards UDP-encapsulated HIP traffic, and in future
extensions, a relay may also forward TCP-encapsulated traffic. The
HIP Relay forwards HIP control packets. NAT traversal for HIP
between two end-hosts may require the use of relays in certain
scenarios. A successful NAT traversal therefore requires at least
the Responder located behind a NAT to register with a HIP Relay.
A HIP Relay MUST silently drop packets to a HIP Relay Client that has
not previously registered with the HIP Relay. The registration
process follows the generic registration extensions defined in
[I-D.ietf-hip-registration] and is illustrated in Figure 1.
HIP HIP
Relay Relay Relay Relay
Client Server Client Server
| 1. I1 | | 1. UDP(I1) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 2. R1(LOCATOR,REG_INFO(RELAY_UDP_HIP,RELAY_UDP_ESP)) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
| | | |
| 3. I2(LOCATOR,REG_REQ(RELAY_UDP_HIP,RELAY_UDP_ESP)) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 4. R2(REG_RES(RELAY_UDP_HIP,RELAY_UDP_ESP),REG_FROM) | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------| |<-------------------------------------------------------+
| |
| 5. Connectivity tests |
|<------------------------------------------------------>|
Figure 1: Example registration to a relay
In the above figure, the end-host is referred to as a relay client Figure 1: Example Registration to a HIP Relay
and the relay middlebox as a relay server. The registration is
piggybacked to a base exchange, but it can be done also using HIP
UPDATE control packets as described in [I-D.ietf-hip-registration].
In step 1, the relay client starts the registration procedure by In step 1, the Initiator starts the registration procedure by sending
sending an I1 packet over the transport layer. The port selection an I1 packet over UDP. It is RECOMMENDED that the Initiator selects
was explained in section Section 3.1. a random port number from the ephemeral port range 49152-65535 for
initiating a base exchange. However, the allocated port MUST be
maintained until all of the corresponding HIP Associations are
closed. Alternatively, a host MAY also use a single fixed port for
initiating all outgoing connections.
In step 2, the Responder lists the services that it supports in the In step 2, the Responder lists the services that it supports in the
R1 packet. The support for HIP-over-UDP relaying is denoted by R1 packet. The support for HIP-over-UDP relaying is denoted by the
RELAY_UDP_HIP value and the support for ESP-over-UDP relaying is RELAY_UDP_HIP value. The R1 does not contain any NAT transform
denoted by a RELAY_UDP_ESP value in the REG_INFO parameter. parameter (see Section 4.1) as discussed in Appendix B.
In step 3, the Initiator selects the services it registers to and In step 3, the Initiator selects the services it registers for and
lists them in the REG_REQ parameter. In this example, the Initiator lists them in the REG_REQ parameter. In this example, the Initiator
registers both to HIP and ESP relay services. registers for HIP Relay service.
In step 4, the relay server concludes the registration procedure with
an R2 packet and acknowledges the registered services in the REG_RES
parameter. The relay may also denote unsuccessful registrations in
the REG_FAILED parameter in R2. After the registration, the hosts
MUST send periodically NAT keepalive packets to each other as defined
later in this document.
In step 5, the client and server handle connectivity tests. The
procedure is described in a later section.
When the ESP relay registration was successful, the relay server uses
the source IP address and port of the R2 packet (HIPPORT) to relay
ESP traffic with the client. This address-port pair of the relay is
referred to as a "leased transport locator" in this document. As the
port number may be shared by multiple clients, the ESP relay MUST
multiplex the ESP traffic based on SPIs and not the just the port
number.
The R2 packet also includes an REG_FROM parameter that indicates the In step 4, the Responder concludes the registration procedure with an
transport locator of the client as observed by the server. The R2 packet and acknowledges the registered services in the REG_RES
transport locator may be translated by a number of NAT middleboxes parameter. The Responder may also denote unsuccessful registrations
between the client and the server. This locator is referred to as in the REG_FAILED parameter in R2. The Responder also includes a
the "relay reflexive transport locator" later in this document. REG_FROM parameter that contains the transport address of the client
as observed by the Relay (Server Reflexive candidate). After the
registration, the Initiator needs to send periodically NAT keep-
alives.
A single server can provide multiple HIP middlebox services or the There are different ways for an Initiator to learn it's publically
services can be distributed among multiple servers. The difference visible IP address and port that are referred to as the "server
between a HIP rendezvous server [I-D.ietf-hip-rvs] and a HIP relay reflexive transport candidate" in this document. This document makes
server depends on the registration. The rendezvous server processing use of two ways:
rules apply when the Responder has registered to a middlebox with the
RVS registration type. Correspondingly, the middlebox applies the
relay extensions defined in this document when the Responder has
registered using the relay registration types. When a single server
provides both rendezvous and relay services, they are multiplexed
depending on the absence or presence of transport layer
encapsulation.
The Relay Client MUST include a LOCATOR parameter in I2 which lists o The Relay client may use STUN servers to detect the server
all of the locators of the Initiator. The Relay Server MUST include reflexive locator, as described in [I-D.ietf-behave-p2p-state].
a LOCATOR parameter in R1, but it is RECOMMENDED that the LOCATOR
parameter includes only the source transport LOCATOR of R1 as the
only locator. The case when the Relay Server includes more locators
may require IP header conversion between IPv4 and IPv6, insertion, or
removal of, UDP header and fragmentation handling. Multiple locators
in R1 is left for further experimentation.
3.3. Base Exchange via Relay o Alternatively, the Relay Client can learn it from the REG_FROM
parameter when registering to a Relay.
It is RECOMMENDED that the Initiator sends an I1 packet over the 3.2. Base Exchange via HIP Relay
transport layer when it is destined to an IPv4 address of the
Responder. Respectively, the Responder MUST respond to a such I1
packet with an R1 packet over the transport layer and using the same
transport protocol. The rest of the base exchange, I2 and R2, MUST
also be sent over the transport layer. However, the transport layer
encapsulation can be unnecessary when there are no NATs between the
Initiator and Responder. This will be detected in the connectivity
tests described in the next section.
When the Initiator has an IPv6 address and it has discovered only an It is RECOMMENDED that the Initiator sends an I1 packet encapsulated
IPv6 address for the peer, it MUST send it directly over IP. In such in UDP when it is destined to an IPv4 address of the Responder.
a case, the Initiator MUST follow the procedures described in Respectively, the Responder MUST respond to a such I1 packet with an
[I-D.ietf-hip-base]. Otherwise, it is RECOMMENDED that the Initiator R1 packet over the transport layer and using the same transport
proceeds as shown in Figure 2. protocol. The rest of the base exchange, I2 and R2, MUST also use
the same transport layer.
I Relay R I HIP Relay R
| 1. I1 | | | 1. UDP(I1) | |
+------------------------------->| 2. I1(RELAY_FROM) | +----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +--------------------------->| | +------------------------------->|
| | | | | |
| | 3. R1(LOCATOR,RELAY_TO) | | | 3. UDP(R1(RELAY_TO)) |
| 4. R1(LOCATOR,RELAY_TO) |<---------------------------+ | 4. UDP(R1(RELAY_TO)) |<-------------------------------+
|<-------------------------------+ | |<-----------------------------+ |
| | | | | |
| 5. I2(LOCATOR) | | | 5. UDP(I2(LOCATOR)) | |
+------------------------------->| | +----------------------------->| |
| | 6. I2(LOCATOR,RELAY_FROM) | | | 6. UDP(I2(LOCATOR,RELAY_FROM)) |
| +--------------------------->| | +------------------------------->|
| | | | | |
| | 7. R2(RELAY_TO) | | | 7. UDP(R2(LOCATOR,RELAY_TO)) |
| 8. R2(RELAY_TO) |<---------------------------+ | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-------------------------------+ | |<-----------------------------+ |
| | | | | |
Figure 2: Base Exchange via a relay Figure 2: Base Exchange via a HIP Relay
In step 1 of the figure, the Initiator discovers the HIT of the In step 1 of Figure 2, the Initiator sends an I1 packet over the
Responder and the IPv4 address of the relay of the Responder. The transport layer to the HIT of the Responder. The source address is
Initiator sends an I1 packet over the transport layer to the HIT of one of the locators of the host. The locators of the end-hosts are
the Responder. The port selection was explained in Section 3.1. The referred as "host candidates" in this document.
source address is one of the routable addresses of the host is called
"unreflexive locators" in this document.
In step 2, the relay receives the I1 packet at port HIPPORT. If the In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If
destination HIT belongs to a registered Responder, the relay the destination HIT belongs to a registered Responder, the Relay
processes the packet. Otherwise, the relay MUST drop the packet. processes the packet. Otherwise, the Relay MUST drop the packet
The relay MUST append a RELAY_FROM parameter to the I1 packet which silently. The Relay appends a RELAY_FROM parameter to the I1 packet
preserves the transport source address and port of the Initiator. which constains the transport source address and port of the I1 as
The relay protects the I1 packet with RELAY_HMAC as described in observed by the Relay. The Relay protects the I1 packet with
[I-D.ietf-hip-rvs], except that the parameter type is different. The RELAY_HMAC as described in [I-D.ietf-hip-rvs], except that the
relay MUST change the transport source to and destination of the parameter type is different. The Relay changes the source and
packet to match the values the Responder used when registering to the destination ports and IP addresses of the packet to match the values
relay, i.e., the reverse of the R2 used in the registration. The the Responder used when registering to the Relay, i.e., the reverse
relay MUST recalculate the transport checksum and forwards the packet of the R2 used in the registration. The Relay MUST recalculate the
to the Responder. transport checksum and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet at the transport In step 3, the Responder receives the I1 packet. The Responder
layer. The Responder MUST process it according to the rules in processes it according to the rules in [I-D.ietf-hip-base]. In
[I-D.ietf-hip-base]. In addition, the Responder MUST validate the addition, the Responder validates the RELAY_HMAC according to
RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the packet if the [I-D.ietf-hip-rvs] and silenty drops the packet if the validation
validation fails. The Responder replies with an R1 packet that MUST fails. The Responder replies with an R1 packet to which it includes
contain a LOCATOR parameter that lists the locators of the Responder. a RELAY_TO parameter. The RELAY_TO parameter contains same
The locator list consists of unreflexive, reflexive and leased information as the RELAY_FROM parameter, i.e., Initiator transport
transport locators of the Responder. The R1 packet also contains a address, but the type of the parameter is different. The RELAY_TO
RELAY_TO parameter. The RELAY_TO parameter contains same information parameter is not integrity protected by the signature of the R1 to
as the RELAY_FROM parameter, i.e., Initiator transport locator, but allow pre-created R1 packets at the Responder.
the type of the parameter is different. The RELAY_TO parameter is
not integrity protected by the signature of the R1 to allow pre-
created R1 packets at the Responder.
In step 4, the relay receives the R1 packet. The relay MUST drop the In step 4, the Relay receives the R1 packet. The Relay drops the
packet if the source HIT belongs to an unregistered host. The relay packet silently if the source HIT belongs to an unregistered host.
MAY verify the signature of the R1 packet and drop it when the The Relay MAY verify the signature of the R1 packet and drop it if
signature is invalid. Otherwise, the relay changes the destination the signature is invalid. Otherwise, the Relay rewrites to source
transport header to match RELAY_TO information, recalculates address and port, changes the destination address and port to match
transport checksum and forwards the packet. RELAY_TO information, recalculates transport checksum and forwards
the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
accordingly to [I-D.ietf-hip-base]. It replies with an I2 packet according to [I-D.ietf-hip-base]. It replies with an I2 packet that
that has the same transport locator as R1, but the source and uses the destination transport address of R1 as the source address
destination ports are swapped. The I2 contains a LOCATOR parameter and port. The I2 contains a LOCATOR parameter that lists all the ICE
containing the listing unreflexive, reflexive and leased transport candidates (offer) of the Initiator. The candidates are encoded
locators of the Initiator using the format defined in Section 5.4.
In step 6, the relay receives the I2 packet. The relay appends a In step 6, the Relay receives the I2 packet. The relay appends a
RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step. RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [I-D.ietf-hip-base]. It replies with an R2 packet and according to [I-D.ietf-hip-base]. It replies with a R2 packet and
includes a RELAY_TO parameter as in step three. The RELAY_TO includes a RELAY_TO parameter as in step three. The R2 packet
parameter is protected by the HMAC. includes a LOCATOR parameter that lists all the ICE candidates
(answer) of the Responder. The RELAY_TO parameter is protected by
the HMAC.
In step 8, the relay processes the R2 as described in step four. The In step 8, the Relay processes the R2 as described in step four. The
relay forwards the packet to the Responder. Relay forwards the packet to the Responder.
3.4. Base Exchange without a Relay 4. Connectivity Tests
A host that has a publicly addressable, fixed IP address MAY exclude 4.1. NAT Transformation Negotiation
registration to a Relay. As the Relay is not present, the host MUST
listen at HIPPORT for transport-encapsulated HIP and ESP packets. An
UDP-encapsulated base exchange with such an host does not have the
RELAY_TO and RELAY_FROM parameters present. Connectivity tests MUST
be handled as defined in the following section before any ESP traffic
is allowed.
3.5. Connectivity Tests This section describes usage of a new optional transform parameter
type. The presence of the parameter in HIP base exchange means that
the host supports all of the extensions defined in this document. If
the transform parameter is used, hosts MUST use a password for STUN
HMACs that is drawn from the DH keying material.
The base exchange is completed with an R2 packet. Then, the state of The transform parameter applies both to the registration to the HIP
the HIP associations at both peers is ESTABLISHED, but the peers MUST Relay as well as to a base exchange between end-hosts. The transform
NOT allow any ESP traffic until the connectivity tests described in negotiation in base exchange is illustrated in Figure 3.
the next section are performed successfully. All of the locators,
except the relay address, are in UNVERIFIED state. In the
connectivity tests, the hosts test connectivity between different
locator pairs in order to find a working one. The connectivity tests
are illustrated in Figure 3. In this example, both hosts are behind
NATs.
I Relay R Initiator Responder
| 2. R2(RELAY_TO) | 1. R2(RELAY_TO) | | 1. UDP(I1) |
+<------------------------------+-------------------------------+ +------------------------------------------------------------->|
| |
| 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT-R:DROP|
+------------------------------------------------------------->X|
| |
| 4. UPDATE(ECHO_REQUEST,FROM_PEER) |
|<--------------------------------------------------------------+
| |
| 5. UPDATE(ECHO_RESP,TO_PEER) |
+-------------------------------------------------------------->+
| | | |
| 6. UPDATE(ECHO_REQUEST,FROM_PEER) | | 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) |
+-------------------------------------------------------------->| |<-------------------------------------------------------------+
| | | |
| 7. UPDATE(ECHO_RESP,TO_PEER) | | 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) |
|<--------------------------------------------------------------+ +------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<-------------------------------------------------------------+
| .... |
Figure 3: Connectivity tests Figure 3: Negotiation of NAT Transforms
The connectivity tests are handled as the mobility extensions defined
in [I-D.ietf-hip-mm] and are therefore subject to the same processing
rules. The packets include ESP_INFO, SEQ, ACK, HMAC, SIGNATURE
parameters that are omitted in this section for simplicity. The
differences to the mobility extensions are described in this section.
In steps 1 and 2, the R2 packet is relayed from the Responder through
the Relay to the Responder. After this, both hosts start
connectivity tests using the return routability tests defined in
[I-D.ietf-hip-mm]. The return routability tests are used to probe
for connectivity between each locator pair obtained from the local
and peer locators obtained during base exchange. The return
routability tests are also used as a UDP hole punching mechanism.
The tests are carried in certain order which determined by the
priorization algorithm defined in the next section.
As an example, let's consider the case where hosts are testing each
others outermost NAT addresses, i.e., relay reflexive transport
locators. In step 3, host I sends an UPDATE message containing an
ECHO_REQUEST to the R. This will punch a hole the NAT of I, but the
NAT of R drops the message because the NAT of R has no state with I.
In step 4, R starts also reachability detection by sending an UPDATE
with ECHO_REQUEST. This traverses the NAT of I successfully because
Initiator had already punched an hole into its NAT in step 3. The
Responder replies using ECHO_RESPONSE in step 5. Upon receiving the
ECHO_RESPONSE, the Responder transitions the address pair to VERIFIED
state.
In step 6, host I starts a new return routability test either due to
a retransmission timer or as a reaction to UPDATE with ECHO_REQUEST
received from R. In step 7, host R receives and sends a response to
I. Upon receiving the response, host R transitions the locator pair
being tested to VERIFIED state.
All locators in UNVERIFIED state MUST be retransmitted RTIME times.
The retransmission packets MUST be paced Ta ms apart as defined in
[I-D.ietf-mmusic-ice]. The retransmission are ordered in a sequence
determined by the priority of the transport locator pairs, as
described in the next section.
The source address of the UPDATE messages containing ECHO_REQUEST
parameter is always an unreflexive IPv4 locator of the host. The
destination locator is the peer's unreflexive, reflexive or leased
transport locator, depending on which address is being tested for
reachability. Implementations may add RTT measurement information to
the ECHO_REQUEST parameter in addition to a nonce.
The UPDATE messages carrying ECHO_REQUEST include a FROM_PEER
parameter. The sender of the UPDATE MUST copy the source address of
the UPDATE to the FROM_PEER parameter. When the peer receives the
UPDATE, it responds with an UPDATE containing and a ECHO_REQUEST and
TO_PEER parameters. The TO_PEER parameter MUST contain the source
address of the UPDATE redundantly. The reason from the FROM_PEER and
TO_PEER parameters is that it is possible to learn new addresses
using them. When there is p2p-unfriendly NAT between the peers, it
may cause translate port number of the UPDATE packets to something
that has not been communicated through the relay before. Such an
addresses are called "peer reflexive transport locators" in this
document. The FROM_PEER and TO_PEER parameters can be used for
detecting peer reflexive locators. The learned locators are added to
the connectivity tests.
UPDATE packets destined to the unreflexive locators are sent directly
over IP. UPDATE packets destined for reflexive peer, relay and
leased locators are sent transport layer encapsulated.
Hosts proceed sequentially through the locator pairs in the order
described in the next section. A host MUST transition the state of
transport locator pairs verified by the return routability tests to
the ACTIVE state. Keepalive mechanisms described in later sections
MUST be applied to refresh the port state in NAT devices for locators
in the ACTIVE state. A host MUST also set up the Security
Associations for the inbound ESP traffic for such locators. The
selection of a default outbound SA is defined in the next section.
3.6. Selecting an Address Pair
This section describes priority ordering of connectivity tests and
locators pair selection based on ICE [I-D.ietf-mmusic-ice]. As part
of the priority calculation, each locator has a preference based on
its type. The values for these preferences are shown in Table 2.
+-----------------------------------+------------+
| Locator Type | Preference |
+-----------------------------------+------------+
| The preferred locator | 127 |
| Unreflexive locator | 126 |
| Peer reflexive transport locator | 120 |
| Relay reflexive transport locator | 100 |
| Leased transport locator | 0 |
+-----------------------------------+------------+
Table 2: Locator Type Preferences
In addition to the "type" priority, the priority of a locator is also In step 1, the Initiator sends an I1 to the Responder. In step 2,
affected by the "local" priority. A (multihoming) host may have the Responder responds with an R1. The R1 contains a list of
multiple locators of same type and SHOULD assign a unique local transforms the Responder supports in NAT_TRANSFORM parameter as shown
priority for each locator. Hosts preferring IPv6 communication can in Table 1.
assign higher local preferences for IPv6 locators than for
unreflexive IPv4 locators. ECHO_REQUEST parameters may include RTT
calculation information that an implementation may use to increase
the local priority. A host SHOULD calculate locator priority based
on the local and type priorities as shown in Figure 4. The locator
priority MUST always be included in the type 3 locator fields in
LOCATOR parameters as described in section Section 4.4.
Locator priority = (2^24) * (type preference) + +--------------+----------------------------------------------------+
(2^8) * (local preference) | Transform | Purpose |
| Type | |
+--------------+----------------------------------------------------+
| RESERVED | Reserved for future use |
| ICE-STUN-UDP | UDP encapsulated control and data traffic with |
| | ICE-based connectivity tests using STUN messages |
+--------------+----------------------------------------------------+
Figure 4: Locator priority Table 1: Locator Transformations
A host SHOULD calculate a priority for each locator pair as shown in
Figure 5. I and R denote the priorities of locators of Initiator and
Responder. The use of the same formula at both ends gives more
guarantees that the peers prefer shortest paths between them. It
also converges the selection of the locator pair towards a symmetric
pair instead of an asymmetric pair even though it is not completely
guaranteed. The reasoning for the formula is described in
[I-D.ietf-mmusic-ice].
Pair priority = 2^32 * MIN(I,R) + 2 * MAX(I,R) + (I > R ? 1 : 0) In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM
parameter. It contains the transform type selected by the Initiator
from the list of transforms offered by the Responder. The I2 also
includes the locators of the Initiator in a LOCATOR parameter.
Figure 5: Pair priority In step 4, the Responder concludes the base exchange with an R2
packet. The Responder includes a LOCATOR parameter in the R2 packet.
After reachability tests, both hosts SHOULD assign the transport 4.2. ICE Procedure
address pair with the highest pair priority as their default outgoing
SA for ESP.
3.7. Mobility Hosts exchange HIP control packets through the HIP Relay.
Connectivity tests are, however, directly exchanged between the
address pairs to determine operational address pairs. If a working
direct path between the hosts is found, also the HIP control traffic
MAY start using it.
When one of the hosts changes its locators, it has to notify its The base exchange is completed with an R2 packet. Then, the state of
peers of the address change. This is handled as described in the the HIP associations at both peers is ESTABLISHED, but the peers MUST
connectivity tests in Section 3.5 with the exception that the UPDATE NOT allow any ESP traffic until the connectivity tests are performed
with parameter LOCATOR is used as the trigger to start connectivity successfully. All of the locators, except the HIP Relay address, are
tests instead of the R2. The UPDATE packet contains a LOCATOR in UNVERIFIED state. In the connectivity tests, the hosts test
parameter listing unreflexive, reflexive and leased transport connectivity between different locator pairs in order to find a
locators of the Initiator. This is illustrated in Figure 6. working one. The connectivity tests are illustrated in Figure 4. In
this example, both hosts are behind NATs.
Mobile Relay Corresponding I HIP Relay R
Node | Node | 2. UDP(R2(LOCATOR,RELAY_TO)) | 1. UDP(R2(LOCATOR,RELAY_TO)) |
| | | |<------------------------------+-------------------------------|
| 1. UPDATE(LOCATOR) | 2. UPDATE(LOCATOR,RELAY_TO) |
+-------------------------------+------------------------------>|
| |
| 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT: DROP|
+------------------------------------------------------------->X|
| |
| 4. UPDATE(ECHO_REQUEST,FROM_PEER) |
|<--------------------------------------------------------------+
| |
| 5. UPDATE(ECHO_RESP,TO_PEER) |
|-------------------------------------------------------------->|
| | | |
| 6. UPDATE(ECHO_REQUEST,FROM_PEER) | | 3. Connectivity tests for address pairs |
|<--------------------------------------------------------------| |<------------------------------------------------------------->|
| | | |
| 7. UPDATE(ECHO_RESP,TO_PEER) | | 4. HIP UPDATE for preferred address pair |
|-------------------------------------------------------------->| |<------------------------------------------------------------->|
| | | |
Figure 6: Handover Figure 4: Connectivity tests
When a mobile host moves from a private address realm to another, it
can obtain the same locator on both networks. To denote that the new
locator requires reachability detection, the mobile host MUST use a
new SPI for the new locator.
A host can also use the UPDATE mechanism can also be used for
switching to a more optimal path after connectivity tests. In the
connectivity tests, the host may implement RTT measurements within
ECHO_REQUEST and ECHO_RESPONSE messages. In some cases the result of
the RTT measurements may indicate that another locator pair is more
optimal than the locator pair resulting from the connectivity and
priority tests. In such a case, the host MAY send UPDATE with
LOCATOR parameter with the optimal locator with the preferred bit on.
This gives the highest priority for the most optimal locator and will
be used if the connectivity tests succeed.
3.8. NAT Keepalives
A NAT can delete the mapping state after a timeout when there is no
traffic refreshing the state. For this reason, both hosts MUST send
keep-alives to each other for all locators pairs that are in the
ACTIVE state. Keepalives MUST be sent every 20 seconds for UDP. The
keepalive is a NOTIFY packet without parameters.
The keep-alives MAY also be used to implement failure detection
between end-hosts as in [I-D.oliva-hiprg-reap4hip] (XX FIXME: this
needs still more details). The basic idea is to keep track of HIP
control and ESP packets received over a transport port. When there
is no HIP or ESP traffic (not even keep-alives) arriving during a
certain time period, the host switches to an alternative locator
pair. The host transitions the default locator pair to the
UNVERIFIED state and replaces the currently default SA to correspond
to the ACTIVE locator pair with the highest priority. The host may
also try to send an UPDATE packet with the LOCATOR parameter after a
certain time period if connectivity is still broken.
End-host may also used the keep-alives to detect loss of connectivity
with relay server. When this occurs, the end-host can register to a
new relay and replace the IP address of the old relay server with a
new one in DNS or DHT.
3.9. Closing of HIP Associations
A host closes a HIP association as described in [I-D.ietf-hip-base]
except that the CLOSE and CLOSE_ACK packets are sent over transport
layer and through the relay as illustrated in Figure 7. Hosts MUST
transition the corresponding locator pairs to the DEPRECATED state
after a successful CLOSE-CLOSE_ACK exchange. The corresponding
inbound and outbound SAs must be deleted on such occasion.
I Relay R
| 1. CLOSE | |
+---------------------------->| 2. CLOSE |
| +-------------------------------->|
| | |
| | 3. CLOSE_ACK |
| 4. CLOSE_ACK |<--------------------------------+
|<----------------------------+ |
| | |
Figure 7: Closing of a HIP association
The hosts may also use the CLOSE mechanism to remove redundant SAs
remaining from the connectivity tests. However, the removal can
prolong the recovery in the event of connectivity failures.
3.10. Communication with HIP Hosts without NAT Traversal Support
The UDP encapsulation of HIP and ESP control packets has not been In steps 1 and 2, the R2 packet is relayed from the Responder through
defined in any other IETF document and legacy hosts drop all UDP the Relay to the Initiator.
encapsulated HIP and ESP traffic. Processing of unknown locator
types terminates the base exchange or UPDATE. As such, the
extensions defined in this document are not completely backwards
compatible and require a minimal support in implementations.
A minimal implementation MUST provide UDP encapsulation of HIP and Afterwards, connectivity tests are started based on the procedure
ESP packets. In such a case, the minimal NAT traversal described in [I-D.rosenberg-mmusic-ice-nonsip] by using the candiates
implementation MUST silently discard the processing of type 3 previously exchanged in the HIP base exchange.
locators to allow communication with implementations supporting NAT
traversal defined in this document. The minimal implementation MUST
support UDP keepalives to refresh state of the NAT(s).
Hosts that conform to [I-D.ietf-hip-mm] respond to UPDATE messages 4.3. NAT Keep-alives
containing an ECHO_REQUEST with an UPDATE message containing an
ECHO_RESPONSE. This completes the connectivity tests for the host
supporting the extensions defined in this document. As long as the
implementation supports UDP encapsulation of HIP control packets,
this requires no changes.
The Relay extensions defined in this document do not work with Data channel keepalives are STUN Binding Indications. Keepalives
minimalistic implementations. When there is a Relay between the MUST be sent every 20 seconds at the minimum when the channel is
hosts, both the Initiator and Responder MUST support the extensions idle. To implement failure tolerance, a host SHOULD have smaller
defined in this document. The presence of RELAY_TO and RELAY_FROM keepalive period. When data traffic is exchanged between the end
parameters denotes the precence of a relay. points then no further STUN keepalives need to be exchanged.
4. Packet Formats 5. Packet Formats
This section defines an UDP-encapsulation packet format for HIP base The following subsections define the parameter and packet encodings.
exchange and control traffic, IPsec ESP BEET-mode traffic and NAT All values MUST be in network byte order.
keep-alive packets.
4.1. HIP Control Packets 5.1. HIP Control Packets
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format for UDP-encapsulated HIP control packets Figure 5: Format for UDP-encapsulated HIP Control Packets
Figure 8 shows how HIP control packets are encapsulated within UDP. HIP control packets are encapsulated in UDP packets like in Section
A minimal UDP packet carries a complete HIP packet in its payload. 2.2 of [RFC3948], "rules for encapsulating IKE messages", except that
a different port number is used. Figure 5 shows the encapsulation:
UDP header is followed by 32 zero bits that can be used to
differentiate HIP control packets from ESP packets. The HIP header
and parameters follow the conventions of [I-D.ietf-hip-base] with the
exception that the HIP header checksum MUST be zero. The HIP header
checksum is zero for two reasons. First, the UDP header contains
already a checksum. Second, the checksum definition in
[I-D.ietf-hip-base] includes the IP addresses in the checksum
calculation. The NATs unaware of HIP cannot recompute the HIP
checksum after changing IP addresses.
Contents of the UDP source and destination ports are described below. A HIP Relay or a Responder without a relay MUST listen at transport
The UDP length and checksum field MUST be computed as described in port HIPPORT for incoming UDP-encapsulated HIP control packets.
[RFC0768]. The HIP header and parameter follow the conventions
[I-D.ietf-hip-base] with the exception that the HIP header checksum
MUST be zero. The HIP header checksum is zero for two reasons.
First, the UDP header contains already a checksum. Second, the
checksum definition in [I-D.ietf-hip-base] includes the IP addresses
in the checksum calculation. The NATs unaware of HIP cannot
recompute the HIP checksum after changing IP addresses.
4.2. Control Channel Keep-Alives 5.2. Keep-Alives
The keep-alive for control channel are UDP encapsulated NOTIFY Control and data channel keep-alives are STUN Binding Indications, as
packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain HIP defined in [I-D.ietf-behave-rfc3489bis]. They use the same UDP
parameters. The NAT traversal mechanisms encapsulate these NOTIFY header as the HIP control packets but there is no non-ESP-marker
packets within the payload of UDP packets. between the UDP header and the STUN header. STUN messages are
demultiplexed from ESP and HIP control messages using the STUN
markers, such as the magic cookie value.
4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters 5.3. Relay and Registration Parameters
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Padding | | Port | Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type [ TBD by IANA:
RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2) RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2) RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2)
RELAY_VIA: (64006 = 2^16 - 2^11 + 2^9 + 6) ] REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ]
<!-- AG: those are not described?
TO_PEER: (64010 = 2^16 - 2^11 + 2^9 + 10)
REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 12) ]
-->
Length 18
Address An IPv6 address or an IPv4 address in IPv4-in-IPv6
format.
Port Transport port number
Figure 9: Format for the RELAY_FROM, RELAY_TO and RELAY_VIA Length 20
Address An IPv6 address or an IPv4 address in "IPv4-compatible
IPv6 address" format
Port Transport port number; zero when plain IP is used
Transport Transport protocol type; zero for UDP
Figure 6: Format for the RELAY_FROM, RELAY_TO and REG_FROM
parameters parameters
Figure 9 shows the format of RELAY_FROM, RELAY_TO and RELAY_VIA
parameters.
4.4. LOCATOR Parameter Format of the RELAY_FROM, RELAY_TO and REG_FROM parameters is shown
in Figure 6. Parameters are identical except for the type field.
5.4. LOCATOR Parameter
The generic LOCATOR parameter format is the same as in The generic LOCATOR parameter format is the same as in
[I-D.ietf-hip-mm]. However, presenting transport locators requires a [I-D.ietf-hip-mm]. However, presenting ICE candidates requires a new
new locator type. The generic and NAT specific locator parameters locator type. The generic and NAT traversal specific locator
are illustrated in Figure 10. parameters are illustrated in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P| | Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 46 skipping to change at page 15, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator | | Locator |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Locator parameter Figure 7: LOCATOR parameter
The individual fields in the LOCATOR parameter are described in The individual fields in the LOCATOR parameter are described in
Table 3. Table 2.
+------------+----------+-------------------------------------------+ +-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose | | Field | Value(s) | Purpose |
+------------+----------+-------------------------------------------+ +-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type | | Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and | | Length | Variable | Length in octets, excluding Type and |
| | | Length fields, and excluding padding. | | | | Length fields and padding |
| Traffic | 0-2 | 2 for unreflexive and leased, 1 for relay | | Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | reflexive | | Type | | ESP (2), or for both (0) |
| Locator | 3 | Transport locator | | Locator | 2 | "Transport address" locator type |
| Type | | | | Type | | |
| Locator | 19 | Length of the Locator field in 4-octet | | Locator | 7 | Length of the Locator field in 4-octet |
| Length | | units | | Length | | units |
| Reserved | 0 | Reserved for future extensions | | Reserved | 0 | Reserved for future extensions |
| Preferred | 0 | Usually zero for type 3 locators | | Preferred | 0 | Not used for transport address locators; |
| (P) bit | | | | (P) bit | | MUST be ignored by the receiver. |
| Locator | Variable | Locator lifetime in seconds | | Locator | Variable | Locator lifetime in seconds |
| Lifetime | | | | Lifetime | | |
| Transport | Variable | Zero for unreflexive and greater than | | Transport | Variable | Transport layer port number |
| Port | | zero otherwise | | Port | | |
| Transport | 0 | Zero for UDP | | Transport | 0 | 0 for UDP |
| Protocol | | | | Protocol | | |
| Kind | Variable | 0 for unreflexive, 1 for relay reflexive, | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | 2 for leased | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator preference, see Section 3.6 | | Priority | Variable | Locator's priority as described in |
| SPI | Variable | 0 for relay reflexive, otherwise greater | | | | [I-D.ietf-mmusic-ice] |
| | | than zero | | SPI | Variable | SPI value which the host expects to see in |
| Locator | Variable | An IPv6 address or an IPv4-in-IPv6 format | | | | incoming ESP packets that use this locator |
| | | IPv4 address[RFC2373] | | Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 |
+------------+----------+-------------------------------------------+ | | | address" format IPv4 address [RFC3513], |
| | | obfuscated by XORring it with the owner's |
| | | HIT |
+-----------+----------+--------------------------------------------+
Table 3: Fields of the locator parameter Table 2: Fields of the LOCATOR parameter
4.5. RELAY_HMAC 5.5. RELAY_HMAC
The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
2^4). It has the same semantics as RVS_HMAC [I-D.ietf-hip-rvs]. 2^4). It has the same semantics as RVS_HMAC [I-D.ietf-hip-rvs].
4.6. Registration Types 5.6. Registration Types
The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contains The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain
values for relay registration. The value for RELAY_UDP_HIP is 2. values for HIP Relay registration. The value for RELAY_UDP_HIP is 2.
The value for RELAY_UDP_ESP is 3. The value for RELAY_UDP_ESP is 3.
4.7. ESP Data Packets 5.7. HIP ESP Data Packet Formats
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ESP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Format for UDP-encapsulated IPsec ESP BEET-mode traffic
Figure 11 shows how IPsec ESP BEET-mode packets are encapsulated
within UDP. Again, a minimal UDP packet carries the ESP packet in
its payload. The contents of the UDP source and destination ports
are described in later sections. The UDP length and checksum field
MUST be computed as described in [RFC0768].
4.8. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP
[RFC3948] describes UDP encapsulation of the IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. This section describes the UDP encapsulation of the tunnel mode. On the wire the HIP ESP packets do not differ from the
BEET mode. transport mode ESP and thus the encapsulation of the HIP ESP packets
is same as the UDP encapsulation transport mode ESP.
4.8.1. UDP Encapsulation of IPsec BEET-Mode ESP
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations enable them to define a pair of IPsec ESP security associations
(SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a (SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a
UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs
that produces UDP-encapsulated BEET-mode ESP data traffic. that produces UDP-encapsulated ESP data traffic.
The management of encryption/authentication protocols and security The management of encryption/authentication protocols and security
parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. The UDP
Additional SA parameters, such as IP addresses and UDP ports, MUST be encapsulation format and processing of HIP ESP traffic is described
defined according to this section. Two SAs MUST be defined on each in Section 6.1 of [I-D.ietf-hip-esp].
host for one HIP association; one for outgoing data and another one
for incoming data.
The BEET mode provides limited tunnel mode semantics without the
regular tunnel mode overhead [I-D.nikander-esp-beet-mode]. In the
BEET mode, transport-layer checksums in the payload data are based on
the HITs. The packet MUST then undergo BEET-mode ESP cryptographic
processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode].
Next, the resulting BEET-mode packet is UDP encapsulated. For this
purpose, a UDP header MUST be inserted between the IP and ESP header.
The source and destination ports are filled in. The UDP checksum
MUST be calculated based on the outer addresses (locators) of the
IPsec security association. The other fields of the UDP header are
computed as described in [RFC0768].
The resulting UDP packet MUST then undergo BEET IP header processing
as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].
Figure 12 illustrates the BEET-mode UDP encapsulation procedure for a
TCP packet.
ORIGINAL TCP PACKET:
+------------------------------------------+
| inner IPv6 hdr | ext hdrs | | |
| with HITs | if present | TCP | Data |
+------------------------------------------+
PACKET AFTER BEET-MODE ESP PROCESSING:
+----------------------------------------------------------+
| inner IPv6 hdr | ESP | dest | | | ESP | ESP |
| with HITs | hdr | opts.| TCP | Data | Trailer | ICV |
+----------------------------------------------------------+
|<------- encryption -------->|
|<----------- integrity ----------->|
FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
+------------------------------------------------------------+
| outer IPv4 | UDP | ESP | dest | | | ESP | ESP |
| hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV |
+------------------------------------------------------------+
|<------- encryption -------->|
|<----------- integrity ----------->|
Figure 12: UDP encapsulation of an IPsec BEET-mode ESP packet
containing a TCP segment
4.8.2. UDP Decapsulation of IPsec BEET-Mode ESP
An incoming UDP-encapsulated IPsec BEET-mode ESP packet is
decapsulated as follows. First, if the UDP checksum is invalid, then
the packet MUST be dropped. Then, the packet MUST be verified as
defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data
contained in the payload of the UDP packet MUST be decrypted as
described in [I-D.nikander-esp-beet-mode].
5. Firewall Traversal
This section describes firewall traversal issues separately from NAT
issues. When the Initiator or the Responder of a HIP association is
behind a firewall, additional issues arise.
The NAT traversal mechanisms described in Section 3 require that the
firewall - stateful or not - allows UDP traffic. At the minimum,
successful firewall control packet traversal requires that the host
behind the firewall is allowed to communicate packets with a HIP
relay (or a Responder without Relay) that is listening on UDP port
HIPPORT. Successful ESP data packet traversal requires the same for
the ESP relay. For unrelayed traffic, the destination port HIPPORT
should be open at the firewall to all hosts behind the firewall.
Most firewall implementations support "UDP connection tracking",
i.e., after a host behind a firewall has initiated UDP communication
to the public Internet, the firewall relays UDP response traffic in
the return direction. If no such return traffic arrives for a
specific period of time, the firewall stops relaying the given IP
address and port pair. The mechanisms described in Section 3 already
enable traversal of such firewalls, if the keep-alive interval used
is less than the refresh interval of the firewall.
When the Initiator is behind a firewall, the NAT traversal mechanisms
described in Section 3 depend on the ability to initiate
communication via UDP to the destination port HIPPORT from arbitrary
source ports and to receive UDP response traffic from that port to
the chosen source port. If the Initiator is behind a firewall that
does not support "UDP connection tracking", the NAT traversal
mechanisms described in Section 3 can still be supported, if the
firewall allows permanently inbound UDP traffic from the port HIPPORT
and destined to arbitrary source IP addresses and UDP ports.
When the Responder is behind a firewall, the NAT traversal mechanisms
described in Section 3 depend on the ability to send and receive UDP
traffic originating from HIPPORT of the HIP and ESP relays. When
unrelayed traffic is preferred, arbitrary source IP addresses and
ports are required.
6. Security Considerations
6.1. A Difference to RFC3948
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of IPsec BEET This issue does not exist with the UDP encapsulation of HIP ESP
mode as described in Section 3, because the Responder use HITs to transport format because the Responder use HITs to distinguish
distinguish between different communication instances. between different communication instances.
6.2. Privacy Considerations 6. Security Considerations
The LOCATORs are sent in plain text. Alternatively, they could be 6.1. Privacy Considerations
encrypted. This option was not chosen to allow packet inspection by
middleboxes. Plain text locators may be useful for HIP-aware The LOCATORs are sent XORed format in plain text in favour of
middleboxes in the future. inspection at HIP-aware middleboxes in the future. The current draft
does not specify encrypted versions of LOCATORs even though it could
be beneficial for privacy reasons.
It is possible that an Initiator or Responder may not want to reveal It is possible that an Initiator or Responder may not want to reveal
all of its locators to its peer. For example, a host may not want to all of its locators to its peer. For example, a host may not want to
reveal the internal topology of the private address realm and it reveal the internal topology of the private address realm and it
discards unreflexive locators. Such behavior creates non-optimal discards host addresses. Such behavior creates non-optimal paths
paths when the hosts are located behind the same NAT. Especially, when the hosts are located behind the same NAT. Especially, this
this could be a problem with a legacy NAT that does not support could be a problem with a legacy NAT that does not support routing
routing from the private address realm back to itself through the from the private address realm back to itself through the outer
outer address of the NAT. This scenario is referred to as the address of the NAT. This scenario is referred to as the hairpin
hairpin problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT, problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT, the
the only option left would be to use a leased transport locator from only option left would be to use a relayed transport address from a
a relay. As a consequence, a host may support locator-based privacy TURN server. As a consequence, a host may support locator-based
by leaving out the reflexive locators. Using only unreflexive privacy by leaving out the reflexive candidates. Using only host
locators can produce suboptimal paths possibly causing congestion. candidates can produce suboptimal paths possibly causing congestion.
The use of relays can be useful for protection against Denial-of- The use of HIP Relays or TURN Relays can be useful for protection
Service attacks. If a Responder reveals only its HIP and ESP relay against Denial-of-Service attacks. If a Responder reveals only its
addresses to malign Initiators, the Initiators can only attack the HIP and ESP relay candidates to malign Initiators, the Initiators can
relays that does not prevent the Responder from initiating new only attack the relays that does not prevent the Responder from
outgoing connections if a path around the relay exists. initiating new outgoing connections if a path around the relay
exists.
6.3. Opportunistic Mode 6.2. Opportunistic Mode
The use of opportunistic HIP is NOT RECOMMENDED and its use is not A HIP Relay should have one address per Relay Client when a HIP Relay
defined in this document. In opportunistic HIP, the Initiator sends is serving more than one Relay Clients and is willing to support
the I1 message with null destination HIT. Private address realms do opportunistic mode. Otherwise, it cannot be guaranteed that the
not have unique addresses by definition. Therefore, opportunistic Relay can deliver the I1 packet to the intended recipient.
mode is subject to failure even when there are no attackers present.
In a normal HIP base exchange, a well-behaving Responder drops the I1
packet when the destination HIT does not belong to it. An attacker
could respond to the I1, but the base exchange would eventually fail
as the attacker would fail to prove its ownership of the destination
HIT of the I1.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
This draft currently uses a UDP port in the "Dynamic and/or Private This draft currently uses a UDP port in the "Dynamic and/or Private
Port" and HIPPORT. Upon publication of this document, IANA is Port" and HIPPORT. Upon publication of this document, IANA is
requested to register a UDP port and the RFC editor is requested to requested to register a UDP port and the RFC editor is requested to
change all occurrences of port HIPPORT to the port IANA has change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial registered. The HIPPORT number 50500 should be used for initial
experimentation. experimentation.
This document updates the IANA Registry for HIP Parameters Types by This document updates the IANA Registry for HIP Parameter Types by
assigning new HIP Parameter Types values for the new HIP Parameters assigning new HIP Parameter Type values for the new HIP Parameters:
defined in Section 4: o RELAY_FROM (defined in Section 4.3) o RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.3) and
RELAY_TO (defined in Section 4.3) o RELAY_VIA (defined in Section RELAY_HMAC (defined in Section 5.5).
4.3) o RELAY_HMAC (defined in Section 4.5)
8. Acknowlegements 8. Contributors
The authors would like to thank Lars Eggert, Vivien Schmitt, Abhinav Marcelo Bagnulo, Jan Melen, Simon Schuetz, Martin Stiemerling, Lars
Pathak and Andrei Gurtov for their contributions to previous versions Eggert, Vivien Schmitt, Abhinav Pathak and Andrei Gurtov have
of this draft. Thanks for Philip Matthews on introducing ICE contributed to the initial versions of this draft.
concepts to the authors and for proposing the initial design. Thanks
for Jonathan Rosenberg and the rest of the MMUSIC WG folks for the
excellent work on ICE. In addition, the authors would like to thank
Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz,
Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander,
Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela,
Samu Varjonen, Dan Wing, Hannes Tschofenig and Jani Hautakorpi for
their comments on this document.
[I-D.nikander-hip-path] presented some initial ideas for NAT 9. Acknowlegements
traversal of HIP communication. The idea was based on NAT detection
using extra parameters in the base exchange. This document takes a
different approach based on ICE.
Simon Schuetz and Martin Stiemerling are partly funded by Ambient Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for
Networks, a research project supported by the European Commission the excellent work on ICE. In addition, the authors would like to
under its Sixth Framework Program. The views and conclusions thank Andrei Gurtov, Tobias Heer, Teemu Koponen, Juhana Mattila,
contained herein are those of the authors and should not be Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne
interpreted as necessarily representing the official policies or Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha
endorsements, either expressed or implied, of the Ambient Networks Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Hannes Tschofenig,
project or the European Commission. Jan Melen, Jani Hautakorpi and Ari Keraenen For their comments on
this document.
Miika Komu is working in the Networking Research group at Helsinki Miika Komu is working in the Networking Research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project Institute for Information Technology (HIIT). The InfraHIP project
was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
Forces and Ericsson. Miika Komu wrote draft-ietf-hip-nat-02 version Forces, and Ericsson and Birdstep.
from scratch based on ICE-related comments from Philip Matthews.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-06 (work in progress),
January 2008.
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
draft-ietf-hip-base-08 (work in progress), June 2007. "Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007.
[I-D.ietf-hip-esp] [I-D.ietf-hip-esp]
Jokela, P., "Using ESP transport format with HIP", Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-06 (work in progress), June 2007. draft-ietf-hip-esp-06 (work in progress), June 2007.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work in Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007. progress), March 2007.
skipping to change at page 26, line 38 skipping to change at page 20, line 14
[I-D.ietf-hip-rvs] [I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.nikander-esp-beet-mode]
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-07
(work in progress), February 2007.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [I-D.rosenberg-mmusic-ice-nonsip]
August 1980. Rosenberg, J., "NICE: Non Session Initiation Protocol
(SIP) usage of Interactive Connectivity Establishment
(ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 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.
9.2. Informative References 10.2. Informative References
[I-D.ietf-behave-p2p-state] [I-D.ietf-behave-p2p-state]
Srisuresh, P., "State of Peer-to-Peer(P2P) Communication Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Across Network Address Translators(NATs)", Peer(P2P) Communication Across Network Address
draft-ietf-behave-p2p-state-03 (work in progress), Translators(NATs)", draft-ietf-behave-p2p-state-06 (work
July 2007. in progress), November 2007.
[I-D.irtf-hiprg-nat] [I-D.irtf-hiprg-nat]
Stiemerling, M., "NAT and Firewall Traversal Issues of Stiemerling, M., "NAT and Firewall Traversal Issues of
Host Identity Protocol (HIP) Communication", Host Identity Protocol (HIP) Communication",
draft-irtf-hiprg-nat-04 (work in progress), March 2007. draft-irtf-hiprg-nat-04 (work in progress), March 2007.
[I-D.nikander-hip-path]
Nikander, P., "Preferred Alternatives for Tunnelling HIP
(PATH)", draft-nikander-hip-path-01 (work in progress),
March 2006.
[I-D.oliva-hiprg-reap4hip]
Oliva, A. and M. Bagnulo, "Fault tolerance configurations
for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work
in progress), July 2007.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
Appendix A. Differences to ICE Appendix A. Firewall Traversal
The protocol extensions defined in this draft are based on ICE. The This section describes firewall traversal issues separately from NAT
extensions are a rough translation of ICE concepts to HIP protocol. issues. When the Initiator or the Responder of a HIP association is
The translation preserved certain concepts as they are, but there are behind a firewall, additional issues arise. The firewall discussion
subtle differences. This section tries to explain how ICE concepts applies both to IPv4 and IPv6 addressing.
were mapped to HIP protocol and what are the differences.
The terminology for this draft is a hybrid of ICE and HIP The NAT traversal mechanisms described in this document require that
terminology. "Agent" was translated to "host" in favour of HIP the firewall - stateful or not - allows UDP traffic. At the minimum,
terminology. Transport address was changed to transport locator. successful firewall control packet traversal requires that the host
Similarly, address pair is denoted as locator pair. This document behind the firewall is allowed to communicate packets with a HIP
does not really talk about "candidate addresses", but just "locators" Relay (or a Responder without HIP Relay) that is listening on UDP
which may or may not be verified using the return routability tests, port HIPPORT. Successful ESP data packet traversal requires the same
in favour of mobility terminology in [I-D.ietf-hip-mm]. Host for the TURN server. For unrelayed traffic, the destination port
candidate of ICE became unreflexive locator, server reflexive HIPPORT should be open at the firewall to all hosts behind the
candidate was mapped to relay reflexive transport locator, peer firewall.
reflexive candidate was mapped to peer reflexive locator and relayed
candidate became leased transport locator.
The component, base and foundation terms are not used in the document Most firewall implementations support "UDP connection tracking",
as there is only a single "media stream" for all (ESP) traffic i.e., after a host behind a firewall has initiated UDP communication
between two hosts. to the public Internet, the firewall accepts UDP response traffic in
the return direction. If no such return traffic arrives for a
specific period of time, the firewall stops accepting the given IP
address and port pair. The mechanisms described in this document
already enable traversal of such firewalls, if the keep-alive
interval used is less than the refresh interval of the firewall.
There is no "lite" version ICE in this document, just full, as the When the Initiator is behind a firewall, the NAT traversal mechanisms
full version is the preferred one also for ICE. One specific described in this document depend on the ability to initiate
scenario defined in this document has some resemblance to the lite communication via UDP to the destination port HIPPORT from arbitrary
ICE. When a Responder is a publicly accessible server with fixed source ports and to receive UDP response traffic from that port to
address, it may exclude the use of the relay. In that case, it does the chosen source port. If the Initiator is behind a firewall that
not have to handle the RELAY parameters but still has to respond to does not support "UDP connection tracking", the NAT traversal
the connectivity checks. mechanisms described in this document can still be supported, if the
firewall allows permanently inbound UDP traffic from the port HIPPORT
and destined to arbitrary source IP addresses and UDP ports.
A connectivity check is not a STUN Binding Request. Instead, it is When the Responder is behind a firewall, the NAT traversal mechanisms
return routability check as defined in [I-D.ietf-hip-mm]. "Triggered described in this document depend on the ability to send and receive
check" occurs when a host receives a UPDATE with ECHO_REQUEST and it UDP traffic originating from HIPPORT of the HIP Relays and TURN
responds using a ECHO_RESPONSE and sends its own ECHO_REQUEST. A servers. When end-to-end traffic is preferred, arbitrary source IP
"check list" is effectively a LOCATOR parameter as defined in addresses and ports are required.
[I-D.ietf-hip-mm]. The term "ordinary check" is not really used in
this document as it HIP packets are retransmitted periodically when
the LOCATORs are in UNVERIFIED state. "Valid list" corresponds to
locator pairs that have been verified successfully by the return
routability tests.
The peers trigger the connectivity checks after the base exchange or Appendix B. Base Exchange without ICE Connectivity Checks
after a base exchange. The conclusion of the connectivity checks,
i.e., selection of the final address pair, differs the most as a
result of fitting the ICE nomination algorithm to HIP mobility
mechanisms. There is no "controlling agent" and the end-hosts make a
local decision on which locator pair to choose. This could lead to
asymmetric address pairs, but the priority algorithm guarantees that
the address pairs converge. Also, there is are no aggressive and
regular nomination modes as a consequence of the lack of controlling
agent.
ICE uses TLS, usernames and passwords as security mechanisms. HIP In certain network environments, the ICE connectivity tests can be
has built-in security mechanisms that preferred over the ones that omitted to reduce initial connection set up latency because base
are used in ICE. exchange acts an implicit connectivity test itself. There are three
assumptions about such as environments. First, the Responder should
have a long-term, fixed locator in the network. Second, the
Responder should not have a HIP Relay configured for itself. Third,
the Initiator can reach the Responder by simply UDP encapsulating HIP
and ESP packets to the host. Detecting and configuring this
particular scenario is prone administrative failure unless carefully
planned.
Appendix B. Document Revision History In such a scenario, the Initiator sends an I1 packet over UDP to the
Responder. The Responder replies with a R1 packet that does not
contain the transform parameter as explained in Section 4.1. The
Initiator receives the R1 packet and determines from the absence of
the transform and RELAY_TO parameters that ICE connectivity tests can
be omitted with the Responder. Finally, the hosts set up IPsec
security associations using the locators observed from the concluding
I2 and R2 packets of the base exchange without ICE connectivity
tests.
Appendix C. IPv4-IPv6 Interoperability
Currently Relay Client and Server do not have to run any ICE
connectivity tests as described in Appendix B. However, it could be
useful for IPv4-IPv6 interoperability when the Relay Server actually
includes both the NAT transform parameter and multiple locators in
R2. The interoperability benefit is that the Relay could support
IPv4-based Initiators and IPv6-based Responders by converting the
network headers and recalculating UDP checksums.
Such an approach is underspecified in this document currently. It is
not yet recommended because it may consume resources at the Relay and
requires also similar conversion support at the TURN relay for data
packets.
Appendix D. Base Exchange through a Rendezvous Server
This section describes handling for a scenario where Initiator looks
up the information of the Responder from DNS and discovers a RVS
record [I-D.ietf-hip-rvs]. In such a case, the Initiator uses its
own HIP Relay to forward HIP traffic to the Rendezvous server. The
Initiator will send the I1 message using the its HIP Relay server
which will then forward it to the RVS server of the responder. The
responder will send the R1 packet directly to the Initiator's HIP
Relay server and the following I2 and R2 packets are also sent
directly using the Relay.
In case the Initiator is not able to distinguish which records are
RVS address records and which are Responders address records, then
the Initiator SHOULD first try to contact the Responder directly and
if none of the addresses is reachable it MAY try out them using its
own HIP Relay as described in the above.
Appendix E. Document Revision History
To be removed upon publication To be removed upon publication
+------------+------------------------------------------------------+ +-----------------------------+-------------------------------------+
| Revision | Comments | | Revision | Comments |
+------------+------------------------------------------------------+ +-----------------------------+-------------------------------------+
| schmitt-00 | Initial version. | | draft-ietf-nat-traversal-00 | Initial version. |
| ietf-00 | Officially adopted as WG item. Solved issues | | draft-ietf-nat-traversal-01 | Draft based on RVS. |
| | 1-9,11,12 | | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and |
| ietf-01 | Solved remaining issues except that relaying ESP and | | | ICE concepts. |
| | mobility were still incomplete. | | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. |
| ietf-02 | Miika rewrote almost from scratch based on ICE. | +-----------------------------+-------------------------------------+
| | Editorial corrections from Simon and Andrei. |
+------------+------------------------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu (editor) Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
Phone: +358503841531 Phone: +358503841531
Fax: +35896949768 Fax: +35896949768
Email: miika@iki.fi Email: miika@iki.fi
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Simon Schuetz Thomas Henderson
NEC Network Laboratories The Boeing Company
Kurfuerstenanlage 36 P.O. Box 3707
Heidelberg 69115 Seattle, WA
Germany USA
Phone: +49 6221 4342 165 Email: thomas.r.henderson@boeing.com
Fax: +49 6221 4342 155
Email: simon.schuetz@netlab.nec.de
URI: http://www.netlab.nec.de/
Martin Stiemerling Philip Matthews
NEC Network Laboratories Avaya
Kurfuerstenanlage 36 100 Innovation Drive
Heidelberg 69115 Ottawa, Ontario K2K 3G7
Germany Canada
Phone: +49 6221 4342 113 Phone: +1 613 592 4343 224
Fax: +49 6221 4342 155 Email: philip_matthews@magma.ca
Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de/ Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com
Ari Keraenen
Ericsson Research Nomadiclab
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 2991
Email: ari.keranen@ericsson.com
Jan Melen
Ericsson Research Nomadiclab
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 2991
Email: jan.melen@ericsson.com
Marcelo Bagnulo
Huawei Lab at UC3M
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/
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. 161 change blocks. 
1003 lines changed or deleted 706 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/