< draft-ietf-hip-nat-traversal-01.txt   draft-ietf-hip-nat-traversal-02.txt >
HIP Working Group M. Komu, Ed. HIP Working Group M. Komu, Ed.
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Standards Track S. Schuetz Intended status: Experimental S. Schuetz
Expires: September 6, 2007 M. Stiemerling Expires: January 7, 2008 M. Stiemerling
NEC NEC
L. Eggert July 6, 2007
Nokia
A. Pathak
IIT Kanpur
March 5, 2007
HIP Extensions for the Traversal of Network Address Translators HIP Extensions for the Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-01 draft-ietf-hip-nat-traversal-02
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 40 skipping to change at page 1, line 36
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 September 6, 2007. This Internet-Draft will expire on January 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies extensions to Host Identity Protocol (HIP) to The Host Identity Protocol (HIP) provides a new namespace that can be
support traversal of Network Address Translator (NAT) middleboxes. used for uniquely identifying hosts in public and also in private
address realms. Usually, HIP control and data traffic cannot
The traversal mechanism tunnels HIP control and data traffic over UDP traverse Network Address Translators (NATs), that hinders general
and enables HIP initiators which MAY be behind NATs to contact HIP deployment. This document specifies NAT traversal extensions for
responders which MAY be behind another NAT. HIP. As HIP is located between network and transport layer, the
extensions also provide general-purpose NAT traversal support for all
high-layer networking applications that run over HIP. The basic
design concepts for these extensions have been adopted from the
Interactive Connectivity Establishment (ICE) protocol to HIP. Using
the specified extensions, two HIP-capable hosts are able to
communicate with each other even when they are in different private
address realms.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5 3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Port Number Selection . . . . . . . . . . . . . . . . . . 6
3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 6 3.2. Relay Registration and NAT Detection . . . . . . . . . . . 6
3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 6 3.3. Base Exchange via Relay . . . . . . . . . . . . . . . . . 8
3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6 3.4. Base Exchange without a Relay . . . . . . . . . . . . . . 10
3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 7 3.5. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 11
3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 8 3.6. Selecting an Address Pair . . . . . . . . . . . . . . . . 13
3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 8 3.7. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 8 3.8. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 10 3.9. Closing of HIP Associations . . . . . . . . . . . . . . . 16
3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 10 3.10. Communication with HIP Hosts without NAT Traversal
3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 11 Support . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 13 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3. Use of the Rendezvous Service when only the 4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 17
Initiator is Behind NAT . . . . . . . . . . . . . . . 15 4.2. Control Channel Keep-Alives . . . . . . . . . . . . . . . 18
3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 17 4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters . . . . . . 18
3.4.1. Rendezvous Client Registration From Behind NAT . . . . 17 4.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 19
3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 18 4.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 20 4.6. Registration Types . . . . . . . . . . . . . . . . . . . . 20
3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 22 4.7. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 21
3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 22 4.8. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 21
3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 25 5. Firewall Traversal . . . . . . . . . . . . . . . . . . . . . . 23
3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 23
3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 29 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 24
3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 29 6.3. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 30 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Rendezvous and Responder Privacy . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Differences to ICE . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 Appendix B. Document Revision History . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Document Revision History . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Terminology
In general, this document borrows the terminology from
[I-D.ietf-hip-base] and [RFC4423]. Additional terms are defined in
the table below." These draft e.g. define "Initiator" and
"Responder"
+---------------------+---------------------------------------------+
| Term | Explanation |
+---------------------+---------------------------------------------+
| Rendezvous server | A host that forwards I1 packets to the |
| | Responder |
| HIP Relay | A host that forwards all HIP control |
| | packets between an Initiator and Responder |
| ESP Relay | A host that forwards ESP traffic between |
| | two HIP-enabled hosts |
| Locator | A routable IPv4 or IPv6 address |
| Transport locator | Transport layer port and the corresponding |
| | IPv4/v6 address |
| Unreflexive locator | An IPv4 or IPv6 address of a network |
| | interface of a host |
| 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
2. Introduction
The Host Identity Protocol (HIP) describes a new communication The Host Identity Protocol (HIP) describes a new communication
mechanism for Internet hosts [RFC4423]. It introduces a new mechanism for Internet hosts [RFC4423]. It introduces a new
namespace and protocol layer between the network and transport layers namespace and protocol layer between the network and transport layers
that decouples the identifier and locator roles to support e.g. that decouples the identifier and locator roles to support mobility
mobility and multihoming in the Internet architecture. 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 Network The HIP protocol [I-D.ietf-hip-base] cannot operate across legacy NAT
Address Translator (NAT) middleboxes, as described in middleboxes as described in [I-D.irtf-hiprg-nat]. This document
[I-D.irtf-hiprg-nat]. This document specifies how HIP can traverse specifies mechanisms that allow HIP to traverse through such NAT
through legacy NAT middleboxes that are not aware of HIP or ESP. The middleboxes that are neither HIP-aware nor ESP-aware, without manual
mechanisms defined in this document do not assume that the NAT configuration of the NAT middleboxes.
middleboxes are reconfigured, as long as they allow UDP traffic.
The use of HIP in NAT traversal has also some additional benefits HIP introduces a new namespace for hosts that decouples the identity
provided by the new namespace. First, it is possible to address of a host from its location [RFC4423]. The namespace consists of
hosts behind a single NAT middlebox in a relatively simple way. The Host Identifiers which are public keys. The hosts create the
NAT middlebox translates the locators, but the Host Identifiers and corresponding private keys by themselves which makes identity theft
ESP SPIs remain the same. Second, multiple services can share the more difficult.
same transport layer port number behind a single NAT. There is no
multiplexing issue as long as these services have different Host
Identifiers.
Several different flavors of NATs exist [RFC2663]. This document The new namespace of HIP has some additional benefits when the
extensions defined in this document are used. First, it is possible
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
describes HIP extensions for the traversal of both Network Address describes HIP extensions for the traversal of both Network Address
Translator (NAT) and Network Address and Port Translator (NAPT) Translator (NAT) and Network Address and Port Translator (NAPT)
middleboxes. It generally uses the term NAT to refer to both types middleboxes. The document generally uses the term NAT to refer to
of middleboxes, unless it needs to distinguish between the two types. both types of middleboxes, unless it needs to distinguish between the
two types.
Three basic cases exist for NAT traversal. In the first case, only Three basic scenarios exist for NAT traversal. In the first case,
the initiator of a HIP base exchange is located behind a NAT. In the only the Initiator of a HIP base exchange is located behind a NAT.
second case, only the responder of a HIP base exchange is located In the second case, only the Responder of a HIP base exchange is
behind a NAT. The respective peer host is assumed to be located at a located behind a NAT. The respective peer is assumed to be located
publicly reachable address in both cases. In the third case, both at a publicly reachable address in both cases. In the third case,
parties are located behind (different) NATs. This document describes both peers are located behind (possible different) NATs. All of the
extensions for the first case in Section 3.3, for the second case in use cases are addressed in the draft in a unified method that has
Section 3.4 and in Section 3.5 for the third case. been adopted from Interactive Connectivity Establishment (ICE)
protocol [I-D.ietf-mmusic-ice] and adapted to HIP.
The mechanisms described here also cover use of rendezvous server Legacy NAT devices do not operate consistently although the behavior
from NATted environments. The rendezvous server MUST be used when for new NAT devices has been unified in [RFC4787]. The HIP protocol
the responder is behind a NAT because otherwise successful NAT extensions in this document make as little assumptions as possible of
traversal cannot be guaranteed. The rendezvous server MUST be the behavior of the NAT devices so that NAT traversal will work even
located in a publicly addressable location. Cascading of multiple with legacy NAT devices in the most general sense. The purpose of
NAT enabled rendezvous servers is not possible, although there may be the extensions is to allow two HIP-enabled hosts to communicate with
other kind of rendezvous servers on the path. The NAT middleboxes each other even if one or both communicating hosts are in private
MUST support address independent mapping in the case where both hosts address realms. With some legacy NAT devices, connecting two hosts
are behind NAT devices. Otherwise, some other external relaying behind different address realms is impossible without relaying all
mechanism MUST be used. Endpoint independent filtering is not traffic through a third party host [I-D.ietf-behave-p2p-state]. As a
required in any of the cases. The NAT categories are defined in consequence, the relay host introduces additional hops between the
[I-D.srisuresh-behave-p2p-state]. 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.
The mechanisms described in this document are based on encapsulating Hosts that always get a public addresses can use the rendezvous
both the control and data traffic in UDP in order to traverse NAT(s). services as described in [I-D.ietf-hip-rvs]. Hosts that can be
The data traffic is assumed to be ESP. Other types of data traffic located in private-address realms may use a transport-layer based
are out of scope for this document. The responder listens at a fixed relay service as defined in this document. Both rendezvous and relay
UDP port number for incoming HIP control packets. The port number services forward HIP control packets, but the main difference is that
can be manually configured to the NAT to allow passing incoming the rendezvous service forwards only the initial I1 packet of the
traffic directly to the host behind the NAT (port forwarding). The base exchange while all other HIP control packets are sent directly
benefit of such a configuration is that it does not require any between the communicating hosts. In contrast, the relay service
rendezvous server for the host behind the NAT. Although this relays all HIP control packets because p2p-unfriendly NAT devices
document does not prevent such configurations, it is out of scope drop the packets otherwise [I-D.ietf-behave-p2p-state]. The peers
because of two drawbacks. First, it allows only a single responder use the control channel to communicate their current locators to each
behind the NAT box. Second, manual configuration through several NAT other to find a direct path for carrying ESP encapsulated data
devices may be difficult or administratively prohibited. 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 mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm], The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice].
allow HIP hosts to change network location during the lifetime of a Two hosts communicate their transport locator (a port and an IP
HIP association. Consequently, hosts need to start using the address) to each other in a base exchange. The local locators are
proposed NAT traversal mechanisms after a mobility event relocates paired with peer locators and the pairs are prioritized according to
one or both peers behind a NAT. They may also stop using the their proximity. The locator pairs are tested sequentially in
proposed mechanisms if they both move to publicly addressable priority order using return routability tests [I-D.ietf-hip-mm].
locations. 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
host moves to a different network. The mobile host communicates its
new location to the corresponding node through the relay server of
its peer and starts the connectivity tests.
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].
2. Detecting NATs 3. HIP Across NATs
In order to know whether to use the NAT traversal mechanisms, HIP This section describes NAT traversal between two HIP end-hosts. A
hosts need to detect the presence and type of NAT middleboxes along successful NAT traversal requires at least the Responder located in a
the path to their peer hosts. This document does not describe any private address realm to register to a relay server. The use of the
new NAT detection mechanism but rather assumes that the NAT is relay is optional when the Responder is located in a public address
detected using some external mechanism. Hence, no special HIP realm without rendezvous server.
parameters are required in HIP control messages to detect NATs. The
NAT detection MUST occur prior to a base exchange, after node
movement and prior to sending UPDATE messages.
For example, STUN [RFC3489] offers a generic mechanism for detecting The base exchange is relayed through the relay server. Next, the
both the presence and type of a NAT. In STUN, the host contacts a hosts test the reachability between the different locators to
STUN server that is always located at a publicly reachable address. construct a direct route. When a direct route is not possible, the
The STUN server replies back and provides information on the NAT hosts resort to ESP relays. When locators of a host change, the
presence and type. 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.
A limitation of STUN is that it cannot detect whether the responder 3.1. Port Number Selection
is behind the same NAT as the initiator. This can lead to an
unoptimal route through the public address of the NAT, especially in
combination the rendezvous extensions that are described later in
this document. In the worst case, the NAT may not be able to forward
the traffic unless it supports "hairpin translation" as described in
[I-D.srisuresh-behave-p2p-state].
To guarantee connectivity behind the same NAT, the initiator MUST This document defines only UDP encapsulation for HIP and ESP packets.
detect the hairpin support of the NAT as described in Further extensions may define bindings for other transport protocols.
[I-D.ietf-behave-nat-behavior-discovery]. If the NAT supports The RECOMMENDED transport protocol is UDP.
hairpinning, the initiator uses the UDP encapsulation procedures
described in the following sections. If the NAT does not support
hairpinning, the initiator SHOULD broadcast a single I1 packet
without UDP encapsulation to the local network. The responder MUST
process the I1 according to [I-D.ietf-hip-base]. However, the
initiator MUST continue with the UDP encapsulation mechanisms
described in the following sections because the responder may
actually be located in a different network.
HIP-aware NATs are not in the scope of this document. In the future, It is RECOMMENDED that an Initiator selects a random port number
it may be possible to use some other protocol that is launched in between the ephemeral port ranged 49152-65535 for initiating a base
parallel with e.g. STUN to detect the presence of HIP aware NATs. exchange even for registration. However, the allocated port MUST be
When the path between the initiator and responder consists of HIP maintained until all of the corresponding Host Associations are
aware NATs, the extensions defined in this document SHOULD NOT be closed. Alternatively, a host MAY also use a single fixed port for
used. initiating all outgoing connections.
3. HIP Across NATs A relay or a Responder without a relay MUST listen at transport port
HIPPORT for incoming UDP-encapsulated HIP control packets.
The HIP base exchange as defined in [I-D.ietf-hip-base] works well in 3.2. Relay Registration and NAT Detection
public networks. However, this does not work with some legacy NATs
that are not able to multiplex HIP or ESP traffic. As a result, such
NATs just drop HIP control traffic and/or ESP data traffic. As a
solution for this, we propose UDP encapsulation of control and data
traffic using a specific scheme described in this document. The
scheme also allows hosts behind NATs to act as servers.
[RFC3948] describes UDP encapsulation of transport and tunnel mode HIP rendezvous servers are used in non-NATted environments and its
ESP packets. This document describes a similar mechanism for BEET use is described in [I-D.ietf-hip-rvs]. This section defines the
mode ESP packets [I-D.nikander-esp-beet-mode]. another types middleboxes, called HIP and ESP Relays, which are used
in NATted environments.
3.1. Packet Formats A HIP relay forwards UDP-encapsulated traffic, and in future
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.
This section defines the UDP-encapsulation packet format for HIP base A relay MUST NOT forward any packets to a host that has not
successfully registered to the relay. The registration process
follows the generic registration extensions defined in
[I-D.ietf-hip-registration]. The registration process is illustrated
in Figure 1.
Relay Relay
Client Server
| 1. I1 |
+------------------------------------------------------->|
| |
| 2. R1(LOCATOR,REG_INFO(RELAY_UDP_HIP,RELAY_UDP_ESP)) |
|<-------------------------------------------------------+
| |
| 3. I2(LOCATOR,REG_REQ(RELAY_UDP_HIP,RELAY_UDP_ESP)) |
+------------------------------------------------------->|
| |
| 4. R2(REG_RES(RELAY_UDP_HIP,RELAY_UDP_ESP),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
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
sending an I1 packet over the transport layer. The port selection
was explained in section Section 3.1.
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
RELAY_UDP_HIP value and the support for ESP-over-UDP relaying is
denoted by a RELAY_UDP_ESP value in the REG_INFO parameter.
In step 3, the Initiator selects the services it registers to and
lists them in the REG_REQ parameter. In this example, the Initiator
registers both to HIP and ESP relay services.
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
transport locator of the client as observed by the server. The
transport locator may be translated by a number of NAT middleboxes
between the client and the server. This locator is referred to as
the "relay reflexive transport locator" later in this document.
A single server can provide multiple HIP middlebox services or the
services can be distributed among multiple servers. The difference
between a HIP rendezvous server [I-D.ietf-hip-rvs] and a HIP relay
server depends on the registration. The rendezvous server processing
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
all of the locators of the Initiator. The Relay Server MUST include
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
It is RECOMMENDED that the Initiator sends an I1 packet over the
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
IPv6 address for the peer, it MUST send it directly over IP. In such
a case, the Initiator MUST follow the procedures described in
[I-D.ietf-hip-base]. Otherwise, it is RECOMMENDED that the Initiator
proceeds as shown in Figure 2.
I Relay R
| 1. I1 | |
+------------------------------->| 2. I1(RELAY_FROM) |
| +--------------------------->|
| | |
| | 3. R1(LOCATOR,RELAY_TO) |
| 4. R1(LOCATOR,RELAY_TO) |<---------------------------+
|<-------------------------------+ |
| | |
| 5. I2(LOCATOR) | |
+------------------------------->| |
| | 6. I2(LOCATOR,RELAY_FROM) |
| +--------------------------->|
| | |
| | 7. R2(RELAY_TO) |
| 8. R2(RELAY_TO) |<---------------------------+
|<-------------------------------+ |
| | |
Figure 2: Base Exchange via a relay
In step 1 of the figure, the Initiator discovers the HIT of the
Responder and the IPv4 address of the relay of the Responder. The
Initiator sends an I1 packet over the transport layer to the HIT of
the Responder. The port selection was explained in Section 3.1. The
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
destination HIT belongs to a registered Responder, the relay
processes the packet. Otherwise, the relay MUST drop the packet.
The relay MUST append a RELAY_FROM parameter to the I1 packet which
preserves the transport source address and port of the Initiator.
The relay protects the I1 packet with RELAY_HMAC as described in
[I-D.ietf-hip-rvs], except that the parameter type is different. The
relay MUST change the transport source to and destination of the
packet to match the values the Responder used when registering to the
relay, i.e., the reverse of the R2 used in the registration. The
relay MUST recalculate the transport checksum and forwards the packet
to the Responder.
In step 3, the Responder receives the I1 packet at the transport
layer. The Responder MUST process it according to the rules in
[I-D.ietf-hip-base]. In addition, the Responder MUST validate the
RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the packet if the
validation fails. The Responder replies with an R1 packet that MUST
contain a LOCATOR parameter that lists the locators of the Responder.
The locator list consists of unreflexive, reflexive and leased
transport locators of the Responder. The R1 packet also contains a
RELAY_TO parameter. The RELAY_TO parameter contains same information
as the RELAY_FROM parameter, i.e., Initiator transport locator, but
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
packet if the source HIT belongs to an unregistered host. The relay
MAY verify the signature of the R1 packet and drop it when the
signature is invalid. Otherwise, the relay changes the destination
transport header to match RELAY_TO information, recalculates
transport checksum and forwards the packet.
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
that has the same transport locator as R1, but the source and
destination ports are swapped. The I2 contains a LOCATOR parameter
containing the listing unreflexive, reflexive and leased transport
locators of the Initiator
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.
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
includes a RELAY_TO parameter as in step three. The RELAY_TO
parameter is protected by the HMAC.
In step 8, the relay processes the R2 as described in step four. The
relay forwards the packet to the Responder.
3.4. Base Exchange without a Relay
A host that has a publicly addressable, fixed IP address MAY exclude
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
The base exchange is completed with an R2 packet. Then, the state of
the HIP associations at both peers is ESTABLISHED, but the peers MUST
NOT allow any ESP traffic until the connectivity tests described in
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
| 2. R2(RELAY_TO) | 1. R2(RELAY_TO) |
+<------------------------------+-------------------------------+
| |
| 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) |
+-------------------------------------------------------------->|
| |
| 7. UPDATE(ECHO_RESP,TO_PEER) |
|<--------------------------------------------------------------+
| |
Figure 3: Connectivity tests
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
affected by the "local" priority. A (multihoming) host may have
multiple locators of same type and SHOULD assign a unique local
priority for each locator. Hosts preferring IPv6 communication can
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)
Figure 4: Locator priority
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)
Figure 5: Pair priority
After reachability tests, both hosts SHOULD assign the transport
address pair with the highest pair priority as their default outgoing
SA for ESP.
3.7. Mobility
When one of the hosts changes its locators, it has to notify its
peers of the address change. This is handled as described in the
connectivity tests in Section 3.5 with the exception that the UPDATE
with parameter LOCATOR is used as the trigger to start connectivity
tests instead of the R2. The UPDATE packet contains a LOCATOR
parameter listing unreflexive, reflexive and leased transport
locators of the Initiator. This is illustrated in Figure 6.
Mobile Relay Corresponding
Node | Node
| | |
| 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) |
|<--------------------------------------------------------------|
| |
| 7. UPDATE(ECHO_RESP,TO_PEER) |
|-------------------------------------------------------------->|
| |
Figure 6: Handover
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
defined in any other IETF document and legacy hosts drop all UDP
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
ESP packets. In such a case, the minimal NAT traversal
implementation MUST silently discard the processing of type 3
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
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
minimalistic implementations. When there is a Relay between the
hosts, both the Initiator and Responder MUST support the extensions
defined in this document. The presence of RELAY_TO and RELAY_FROM
parameters denotes the precence of a relay.
4. Packet Formats
This section defines an UDP-encapsulation packet format for HIP base
exchange and control traffic, IPsec ESP BEET-mode traffic and NAT exchange and control traffic, IPsec ESP BEET-mode traffic and NAT
keep-alive. keep-alive packets.
3.1.1. Control Traffic 4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for UDP-encapsulated HIP control traffic. Figure 8: Format for UDP-encapsulated HIP control packets
Figure 1 shows how HIP control packets are encapsulated within UDP. Figure 8 shows how HIP control packets are encapsulated within UDP.
A minimal UDP packet carries a complete HIP packet in its payload. A minimal UDP packet carries a complete HIP packet in its payload.
Contents of the UDP source and destination ports are described below. Contents of the UDP source and destination ports are described below.
The UDP length and checksum field MUST be computed as described in The UDP length and checksum field MUST be computed as described in
[RFC0768]. The HIP header and parameter follow the conventions [RFC0768]. The HIP header and parameter follow the conventions
[I-D.ietf-hip-base] with the exception that the HIP header checksum [I-D.ietf-hip-base] with the exception that the HIP header checksum
MUST be zero. The HIP headers checksum is zero for two reasons. MUST be zero. The HIP header checksum is zero for two reasons.
First, the UDP header contains already a checksum. Second, the First, the UDP header contains already a checksum. Second, the
checksum definition in [I-D.ietf-hip-base] includes the IP addresses checksum definition in [I-D.ietf-hip-base] includes the IP addresses
in the checksum calculation which is not applicable on HIP unaware in the checksum calculation. The NATs unaware of HIP cannot
NAT devices. recompute the HIP checksum after changing IP addresses.
3.1.2. Control Channel Keep-Alives 4.2. Control Channel Keep-Alives
The keep-alive for control channel are basically UDP encapsulated The keep-alive for control channel are UDP encapsulated NOTIFY
NOTIFY packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain HIP
HIP parameters. The NAT traversal mechanisms encapsulate these parameters. The NAT traversal mechanisms encapsulate these NOTIFY
NOTIFY packets within the payload of UDP packets. packets within the payload of UDP packets.
4.3. RELAY_FROM, RELAY_TO and RELAY_VIA Parameters
3.1.3. Data Traffic
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ESP Header ~ | Address |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic. Type [ TBD by IANA:
RELAY_FROM: (63998 = 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) ]
<!-- 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 2 shows how IPsec ESP BEET-mode packets are encapsulated Figure 9: Format for the RELAY_FROM, RELAY_TO and RELAY_VIA
within UDP. Again, a minimal UDP packet carries the ESP packet in parameters
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].
3.1.4. FROM_NAT Parameter Figure 9 shows the format of RELAY_FROM, RELAY_TO and RELAY_VIA
parameters.
4.4. LOCATOR Parameter
The generic LOCATOR parameter format is the same as in
[I-D.ietf-hip-mm]. However, presenting transport locators requires a
new locator type. The generic and NAT specific locator parameters
are illustrated in Figure 10.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| | | |
| Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | Padding | . .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Loc Type = 2 | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto | Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ] Figure 10: Locator parameter
Length 18
Address An IPv6 address or an IPv4 address in IPv4-in-IPv6
format.
UDP Port A UDP port number
Figure 3: Format for the FROM_NAT Parameter The individual fields in the LOCATOR parameter are described in
Table 3.
Figure 3 shows FROM_NAT parameter. The use of this parameter is +------------+----------+-------------------------------------------+
described in the following sections. | Field | Value(s) | Purpose |
+------------+----------+-------------------------------------------+
| Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and |
| | | Length fields, and excluding padding. |
| Traffic | 0-2 | 2 for unreflexive and leased, 1 for relay |
| Type | | reflexive |
| Locator | 3 | Transport locator |
| Type | | |
| Locator | 19 | Length of the Locator field in 4-octet |
| Length | | units |
| Reserved | 0 | Reserved for future extensions |
| Preferred | 0 | Usually zero for type 3 locators |
| (P) bit | | |
| Locator | Variable | Locator lifetime in seconds |
| Lifetime | | |
| Transport | Variable | Zero for unreflexive and greater than |
| Port | | zero otherwise |
| Transport | 0 | Zero for UDP |
| Protocol | | |
| Kind | Variable | 0 for unreflexive, 1 for relay reflexive, |
| | | 2 for leased |
| Priority | Variable | Locator preference, see Section 3.6 |
| SPI | Variable | 0 for relay reflexive, otherwise greater |
| | | than zero |
| Locator | Variable | An IPv6 address or an IPv4-in-IPv6 format |
| | | IPv4 address[RFC2373] |
+------------+----------+-------------------------------------------+
3.1.5. VIA_RVS_NAT Parameter Table 3: Fields of the locator parameter
4.5. RELAY_HMAC
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].
4.6. Registration Types
The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contains
values for relay registration. The value for RELAY_UDP_HIP is 2.
The value for RELAY_UDP_ESP is 3.
4.7. ESP Data 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | ~ ESP Header ~
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ] Figure 11: Format for UDP-encapsulated IPsec ESP BEET-mode traffic
Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address
UDP Port A UDP port
Figure 4: Format for the VIA_RVS_NAT Parameter
Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for Figure 11 shows how IPsec ESP BEET-mode packets are encapsulated
diagnostic purposes, similarly as VIA_RVS parameter in within UDP. Again, a minimal UDP packet carries the ESP packet in
[I-D.ietf-hip-rvs]. The exact use of this parameter is described in its payload. The contents of the UDP source and destination ports
later sections. are described in later sections. The UDP length and checksum field
MUST be computed as described in [RFC0768].
3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP 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. This section describes the UDP encapsulation of the
BEET mode. BEET mode.
3.2.1. UDP Encapsulation of IPsec BEET-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 result in UDP-encapsulated BEET-mode ESP data traffic. that produces UDP-encapsulated BEET-mode ESP data traffic.
The management of encryption and authentication protocols and The management of encryption/authentication protocols and security
security parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. parameter indices (SPIs) is defined in [I-D.ietf-hip-esp].
Additional SA parameters, such as IP addresses and UDP ports, MUST be Additional SA parameters, such as IP addresses and UDP ports, MUST be
defined according to this section. Two SAs MUST be defined on each defined according to this section. Two SAs MUST be defined on each
host for one HIP association; one for outgoing data and another one host for one HIP association; one for outgoing data and another one
for incoming data. for incoming data.
The BEET mode provides limited tunnel mode semantics without the The BEET mode provides limited tunnel mode semantics without the
regular tunnel mode overhead. [I-D.nikander-esp-beet-mode] In 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 BEET mode, transport-layer checksums in the payload data are based on
the HITs. The packet MUST then undergo BEET-mode ESP cryptographic 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]. 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 Next, the resulting BEET-mode packet is UDP encapsulated. For this
purpose, a UDP header MUST be inserted between the IP and ESP header. purpose, a UDP header MUST be inserted between the IP and ESP header.
The source and destination ports are filled in. The UDP checksum The source and destination ports are filled in. The UDP checksum
MUST be calculated based on the outer addresses (locators) of the MUST be calculated based on the outer addresses (locators) of the
IPsec security association. The other fields of the UDP header are IPsec security association. The other fields of the UDP header are
computed as described in [RFC0768]. computed as described in [RFC0768].
The resulting UDP packet MUST then undergo BEET IP header processing The resulting UDP packet MUST then undergo BEET IP header processing
as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].
Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a Figure 12 illustrates the BEET-mode UDP encapsulation procedure for a
TCP packet. TCP packet.
ORIGINAL TCP PACKET: ORIGINAL TCP PACKET:
+------------------------------------------+ +------------------------------------------+
| inner IPv6 hdr | ext hdrs | | | | inner IPv6 hdr | ext hdrs | | |
| with HITs | if present | TCP | Data | | with HITs | if present | TCP | Data |
+------------------------------------------+ +------------------------------------------+
PACKET AFTER BEET-MODE ESP PROCESSING: PACKET AFTER BEET-MODE ESP PROCESSING:
+----------------------------------------------------------+ +----------------------------------------------------------+
skipping to change at page 9, line 46 skipping to change at page 22, line 40
|<----------- integrity ----------->| |<----------- integrity ----------->|
FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING: FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
+------------------------------------------------------------+ +------------------------------------------------------------+
| outer IPv4 | UDP | ESP | dest | | | ESP | ESP | | outer IPv4 | UDP | ESP | dest | | | ESP | ESP |
| hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV | | hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV |
+------------------------------------------------------------+ +------------------------------------------------------------+
|<------- encryption -------->| |<------- encryption -------->|
|<----------- integrity ----------->| |<----------- integrity ----------->|
Figure 5: UDP Encapsulation of an IPsec BEET-mode ESP packet Figure 12: UDP encapsulation of an IPsec BEET-mode ESP packet
containing a TCP segment. containing a TCP segment
3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP 4.8.2. UDP Decapsulation of IPsec BEET-Mode ESP
An incoming UDP-encapsulated IPsec BEET-mode ESP packet is An incoming UDP-encapsulated IPsec BEET-mode ESP packet is
decapsulated as follows. First, if the UDP checksum is invalid, then decapsulated as follows. First, if the UDP checksum is invalid, then
the packet MUST be dropped. Then, the packet MUST be verified as 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 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 contained in the payload of the UDP packet MUST be decrypted as
described in [I-D.nikander-esp-beet-mode]. described in [I-D.nikander-esp-beet-mode].
The NAT traversal methods described in this section are based on 5. Firewall Traversal
connection reversal and UDP hole punching similar to
[I-D.ietf-behave-nat-udp]. However, the methods in this section are
adapted for HIP purposes, especially with the rendezvous server in
mind.
3.3. Initiator Behind NAT
This section discusses mechanisms to reach a HIP responder located in
publicly addressable network by a HIP initiator that is located
behind a NAT. The section describes also the case where the
responder is using a rendezvous service.
Table 1 lists some short-hand notations used in this section. For
simplicity, the ports mangled by NAT are presented as example port
numbers (11111, 22222, etc) instead of symbolic ones. In the
examples, we assume that the NAT(s) timeout after the I1-R1 exchange
over UDP because of e.g large RTT or high puzzle difficulty. In such
a case, the NAT drops the related UDP port state and port numbers
change for the I2-R2 exchange.
+------------------+------------------------------------------------+
| Notation | Explanation |
+------------------+------------------------------------------------+
| HIT-I | Initiator's HIT |
| HIT-R | Responder's HIT |
| IP-I | Initiator's IP address |
| IP-R | Responder's IP address |
| IP-RVS | IP address of the responder's rendezvous |
| | server |
| IP-NAT-I | Public IP of the NAT of the initiator |
| IP-NAT-R | Public IP of the NAT of the responder |
| UDP(50500,11111) | UDP packet with source port 50500 and |
| | destination port 11111 |
| UDP(11111,22222) | Example port numbers mangled by a NAT |
| UDP(44444,22222) | Port 44444 is used throughout the examples to |
| | denote the NAT mangled source port of I2 as |
| | received by the rendezvous server during the |
| | registration |
+------------------+------------------------------------------------+
Table 1: Notations Used in This Section
3.3.1. NAT Traversal of HIP Control Traffic
This section describes the details of enabling NAT traversal for HIP
control traffic for the base exchange [I-D.ietf-hip-base] through UDP
encapsulation for the case when the initiator of the association is
located behind a NAT and the responder is located in a publicly
addressable network. UDP-encapsulated HIP control traffic MUST use
the packet formats described in Section 3.1. When sending UDP-
encapsulated HIP control traffic, a HIP implementation MUST zero the
HIP header checksum before calculating the UDP checksum. The
receiver MUST only verify the correctness of the UDP checksum and
MUST NOT verify the checksum of the HIP header.
The initiator of a UDP-encapsulated HIP base exchange MUST use the
UDP destination port 50500 for all control packets it sends. It is
RECOMMENDED to use 50500 as the source port as well, but an
implementation MAY use a (randomly selected) unoccupied source port.
If it uses a random source port, it MUST listen for and accept
arriving HIP control/ESP Data packets on this port until the
corresponding HIP association is torn down. The random source port
is RECOMMENDED to be in the range of the dynamic and private ports
(49152-65535). Using a random source port, instead of a fixed one,
enables to have multiple clients behind a NAT middlebox that supports
only address translation but no port translation. This is referred
to as port overloading in [I-D.ietf-behave-nat-udp].
The responder of a UDP-encapsulated HIP base exchange MUST use 50500
as the source port for all UDP-encapsulated control packets it sends.
The source address for all the packets that the responder sends MUST
be the same as the IP address on which responder receives packets
from initiator. The responder MUST respond to any arriving UDP-
encapsulated control message using UDP encapsulation as well. Hosts
MUST process UDP-encapsulated base exchange messages equivalently to
non-encapsulated messages, i.e., according to [I-D.ietf-hip-base].
The remainder of this section clarifies this process through an
example which is illustrated in Figure 6. It shows an initiator with
the private address IP-I behind a NAT. The NAT has the public IP
address as NAT. The responder is in a publicly addressable location
IP-R.
+---+ +---+ +---+
| |----(1)--->| |---------------(2)-------------->| |
| | | N | | |
| |<---(4)----| A |<--------------(3)---------------| |
| I | | T | | R |
| |----(5)--->| - |---------------(6)-------------->| |
| | | I | | |
| |<---(8)----| |<--------------(7)---------------| |
+---+ +---+ +---+
1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R)
3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I)
4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R)
7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I)
8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator
behind a NAT, responder in a publicly addressable location).
Before beginning the base exchange, the initiator detects that it is
behind a NAT through some external mechanism, e.g. STUN. The
initiator starts the base exchange by sending a UDP-encapsulated I1
packet to the responder. According to the rules specified above, the
source IP address of this I1 packet is IP-I and its source UDP port
is 50500. It is addressed to IP-R on port 50500. The NAT in
Figure 6 forwards the I1 but substitutes the source address IP-I with
its own public address IP-NAT-I and the source UDP port 50500 with
11111.
When the responder in Figure 6 receives the UDP-encapsulated I1
packet on UDP port 50500, it decapsulates the packet and processes
the decapsulated packet according to [I-D.ietf-hip-base]. The
responder replies back with a UDP-encapsulated R1 using the addresses
and port information of I1. Thus, the R1 packet is destined to the
source IP address and UDP port of the I1, i.e., IP address IP-NAT-I
and port 11111. The NAT receives the I1 and substitutes the
destination of this packet with the initiator address (IP-I) and port
information (50500).
The initiator receives a UDP-encapsulated R1 packet from the
responder, decapsulates and processes it according to
[I-D.ietf-hip-base]. When it responds with a UDP-encapsulated I2
packet, it uses the same IP source and destination addresses and UDP
source and destination ports that it used for sending the
corresponding I1 packet, i.e., the packet is addressed from IP-I port
50500 to IP-R port 50500. The NAT again substitutes the source
information. For illustration purposes, the NAT state times out and
it chooses a different source port (22222) for the I2 than for the I1
(11111).
When a responder receives a UDP-encapsulated I2 packet destined to
UDP port 50500, it MUST use the UDP source port contained in this
packet for further HIP communications with the initiator. It then
processes the I2 packet according to [I-D.ietf-hip-base]. When it
responds with an R2 message, it UDP-encapsulates the message, using
the UDP source port of the I2 packet as the destination UDP port, and
sends it to the source IP address of the I2 packet, i.e., it sends
the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT
again replaces the destination information in the R2 with IP-I port
50500
Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT
state to persist. This means that the NAT uses the same port for the
I1-R1 exchange to translate as the I2-R2 exchange. However, the host
MUST handle even the case where the NAT state times out between the
two exchanges and the I1 and I2 arrive from different UDP source
ports and/or IP addresses, as illustrated in Figure 6.
3.3.2. NAT Traversal of HIP Data Traffic
This section describes the details of enabling NAT traversal of HIP
data traffic. As described in Section 3, HIP data traffic is carried
in UDP-encapsulated IPsec BEET-mode ESP packets.
3.3.2.1. IPsec BEET-Mode Security Associations
The initiator MUST use UDP destination port 50500 for all UDP-
encapsulated ESP packets it sends. It MAY also use port 50500 as
source port or it MAY use a random source port. If it uses a random
source port, it MUST listen for and accept arriving UDP-encapsulated
ESP packets on this port until the corresponding HIP association is
torn down.
The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST
use 50500 as the source port for all UDP-encapsulated ESP packets it
sends. The destination port is the port from which the responder is
receiving UDP encapsulated ESP data from the initiator.
Both the initiator and the responder of a HIP association MUST define
BEET mode with UDP encapsulation as the IPsec mode for the SA after a
successful base exchange. The inner source address MUST be the local
HIT used during base exchange and the inner destination address MUST
be the HIT of the peer. The other parts of the SA are described in
individual sections.
3.3.2.1.1. Security Associations at the Initiator
The initiator of a UDP-encapsulated base exchange defines its
outbound SA as shown in Table 2
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | The peer IP address to which base exchange packets |
| address | were transmitted |
| UDP src port | The port number as chosen for I2 packet in base |
| | exchange |
| UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+
Table 2: Outbound SA at initiator
The initiator of a UDP-encapsulated base exchange defines its inbound
SA as shown in Table 3
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The peer IP address to which base exchange packets |
| address | were transmitted |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src port | Port 50500 |
| UDP dst port | Initiator MUST use the UDP source port it uses in |
| | the outbound SA here |
+--------------+----------------------------------------------------+
Table 3: Inbound SA at initiator
3.3.2.1.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 4.
+-------------+-----------------------------------------------------+
| Field | Value |
+-------------+-----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | Peer IP address of the I2 packet received during |
| address | the base exchange |
| UDP src | Port 50500 |
| port | |
| UDP dst | Source UDP port of the I2 packet received from the |
| port | initiator during base exchange |
+-------------+-----------------------------------------------------+
Table 4: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 5
+-------------+-----------------------------------------------------+
| Field | Value |
+-------------+-----------------------------------------------------+
| Outer src | Source IP address of the I2 packet received from |
| address | the initiator during base exchange |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src | Source UDP port of the I2 packet received from the |
| port | initiator during base exchange |
| UDP dst | Port 50500 |
| port | |
+-------------+-----------------------------------------------------+
Table 5: Inbound SA at responder
3.3.3. Use of the Rendezvous Service when only the Initiator is Behind
NAT
The rendezvous extensions for HIP without NAT traversal have been
defined in [I-D.ietf-hip-rvs]. This section addresses only the
scenario where a NATted HIP node uses the rendezvous service to
contact another HIP node in a publicly addressable network. Figure 7
illustrates the mechanism described in this section.
A rendezvous server MUST listen on UDP port 50500 for incoming UDP
encapsulated I1 packets. However, in this specific case with only
the initiator behind NAT, the rendezvous server MUST NOT relay the I1
packets. Instead, the rendezvous server replies to the initiator
with a NOTIFY message that includes the responder's locator in a
VIA_RVS parameter. The rendezvous server can differentiate this
scenario from the others because the I1 arrives UDP encapsulated, but
the responder has registered without UDP encapsulation.
Upon receiving the NOTIFY with the locators of the responder through
the NAT, the initiator MUST send an I1 to the responder. However, it
MUST continue retransmissions using the RVS location. This is
mandatory because NOTIFY messages are not protected with signatures
and can be forged by a rogue host.
When the initiator receives an R1 through the NAT, the responder
verifies the integrity of the packet and replies with an I2. The
responder should be aware that the I2 may arrive from a different
port than the I1. In such a case, the responder should send the R2
to the source port of I2.
+---+ +---+ +-------+ +---+
| |----(1)--->| |---------------(2)-->| | | |
| | | | | RVS R | | |
| |<---(4)----| |<--------------(3)---| | | |
| | | | +-------+ | |
| | | N | | |
| |----(5)--->| A |---------------(6)-------------->| |
| I | | T | | R |
| |<---(8)----| - |<--------------(7)---------------| |
| | | T | | |
| |----(9)--->| |---------------(10)------------->| |
| | | | | |
| |<---(11)---| |<--------------(12)--------------| |
+---+ +---+ +---+
1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))
4. IP(IP-RVS, IP-I) UDP(50500, 50500)
NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))
5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R)
7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I)
8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R)
11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I)
12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS
(initiator behind a NAT, responder and RVS on the public Internet).
3.4. Responder Behind NAT
This section discusses mechanisms to reach a HIP responder that is
located behind a NAT. This section assumes that the initiator is
located on publicly addressable network. The initiator contacts the
responder through an RVS server.
3.4.1. Rendezvous Client Registration From Behind NAT
The rendezvous client registration [I-D.ietf-hip-rvs] describes the
case when rendezvous client is present in publicly addressable
network. This section defines an extension to the rendezvous client
registration for the case when the rendezvous client has detected
that it is behind a NAT. The process in the NAT case is identical to
the case without NAT, except that UDP encapsulation is used. The
registration is illustrated in Figure 8.
A node behind a NAT MUST first register to the RVS when it is going
to act as a responder for some other nodes. The node (i.e.
rendezvous client) performs a base exchange with the RVS over UDP as
described in Section 3.3 by sending I1 UDP encapsulated and 50500 as
destination port number. RVS sends REG_INFO parameter in R1 to which
rendezvous client replies with REG_REQ paramter in I2. Both I1 and
R1 are sent using UDP-encapsulation. If RVS grants service to the
rendezvous client, it MUST store the source IP address and source
port number of the I2 UDP packet that it had received from the
rendezvous client during base exchange. The source IP address
belongs to the NAT and the source port number is the NAT mangled
port. RVS then replies with REG_RESP in R2 over UDP. If the
registration process results in a successful REG_RESP, the rendezvous
client MUST send NAT keepalives (Section 3.1.2) to keep the mapping
in the NAT with the RVS open. The NAT keepalives sent from
rendezvous client to the RVS MUST have the same source port as the I2
packet.
When the RVS receives an I1 packet from a HIP node to be relayed to
the successfully registered rendezvous client behind NAT, RVS MUST
relay the I1 over UDP with the destination port as the one stored
during registration. The RVS also zeroes the HIP header checksum of
the I1. This process is explained in Section 3.4.2.
+---+ +---+ +---+
| |----(1)--->| |---------------(2)-------------->| |
| | | N | | |
| |<---(4)----| A |<--------------(3)---------------| |
| I | | T | | R |
| |----(5)--->| - |---------------(6)-------------->| |
| | | I | | |
| |<---(8)----| |<--------------(7)---------------| |
+---+ +---+ +---+
Initiator = Rendezvous client, Responder = Rendezvous server
1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I1(HIT-I, HIT-R)
3. IP(IP-R, IP-NAT-I) UDP(50500, 33333)
R1(HIT-R, HIT-I, REG_INFO)
4. IP(IP-R, IP-I) UDP(50500, 50500)
R1(HIT-R, HIT-I, REG_INFO)
5. IP(IP-I, IP-R) UDP(50500, 50500)
I2(HIT-I, HIT-R, REG_REQ)
6. IP(IP-NAT-I, IP-R) UDP(44444, 50500)
I2(HIT-I, HIT-R, REG_REQ)
7. IP(IP-R, IP-NAT-I) UDP(50500, 44444)
R2(HIT-R, HIT-I, REG_RES)
8. IP(IP-R, IP-I) UDP(50500, 50500)
R2(HIT-R, HIT-I, REG_RES)
Figure 8: Rendezvous NAT Client Registration
3.4.2. NAT Traversal of HIP Control Traffic
This section describes the details of enabling NAT traversal for base
exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for
the case when the HIP initiator is on publicly addressable network
and the HIP responder is behind NAT. The process is illustrated in
Figure 9.
Before the HIP base exchange starts, the responder of the HIP base
exchange MUST have completed a successful rendezvous client
registration using the scheme defined in Section 3.4.1.
The initiator of the HIP base exchange sends a plain I1 packet
(without UDP encapsulation) to the RVS as described in
[I-D.ietf-hip-rvs]. In this case, the rendezvous server detects that
the I1 is not UDP encapsulated, but the rendezvous client has
registered using UDP encapsulation.
To relay the I1 packet, RVS MUST zero the HIP header checksum from
the I1 packet. RVS MUST add a FROM parameter, as described in
[I-D.ietf-hip-rvs], which contains the IP address of HIP initiator.
The FROM parameter is integrity protected by a RVS_HMAC parameter as
described in [I-D.ietf-hip-rvs]. RVS replaces the destination IP
address in the IP header of the packet with IP that it had stored
during the rendezvous client registration (which is the IP address of
the outermost NAT behind which rendezvous client is located). It
MUST then encapsulate the I1 packet within UDP. The source port in
the UDP header MUST be 50500 and the destination port MUST be the
same as the source port number (44444) of the I2 packet which it had
stored during the registration process. RVS then recomputes the IP
header checksum and sends the packet.
+-------+
| |
+----->| RVS +-----+ +----+
+---+ | | | | | | +---+
| |---(1)---+ +-------+ +----(2)--->| |---(3)--->| |
| | | N | | |
| |<------------------(5)--------------------| A |<--(4)----| |
| I | | T | | R |
| |-------------------(6)------------------->| - |---(7)--->| |
| | | R | | |
| |<------------------(9)--------------------| |<--(8)----| |
+---+ +----+ +---+
1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R)
2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
3. IP(IP-RVS, IP-R) UDP(50500, 50500)
I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
4. IP(IP-R, IP-I)
UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
5. IP(IP-NAT-R, IP-I)
UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)
6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R)
7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I)
Figure 9: UDP-encapsulated HIP base exchange (initiator on public
Internet, responder behind a NAT).
The relayed I1 packet travels from RVS to the NAT. The NAT changes
the destination IP address of the UDP encapsulated I1 packet, and the
destination port number in the UDP header. The responder accepts the
packet from the RVS and processes it according to [I-D.ietf-hip-rvs].
The resulting R1 must be encapsulated within UDP. The responder MAY
append a VIA_RVS_NAT parameter to the message, which contains the IP
address of the rendezvous and the port the rendezvous server used for
relaying the I1. The RECOMMENDED source port is 50500 and the
destination port number MUST be 50500. The destination address in
the IP header MUST be the same as the one specified in the FROM
parameter of the relayed I1 packet.
The initiator MUST listen on port 50500 and it receives the UDP
encapsulated R1. After verifying the HIP packet, it concludes that
the responder is behind a NAT because the packet was UDP
encapsulated. The initiator processes the R1 control packet
according to [I-D.ietf-hip-base] and replies using I2 that is UDP
encapsulated. The addresses and ports are derived from the received
R1.
The NAT translates and forwards the UDP encapsulated I2 packet to the
responder. The resulting R2 packet is also UDP encapsulated using
the address and port information from the received I2 packet.
3.4.3. NAT Traversal of HIP Data Traffic
After a successful base exchange, both of the HIP nodes have
communicated all the necessary information to establish UDP-
encapsulated BEET mode Security Associations. The following section
describes inbound and outbound security associations at initiator and
responder.
3.4.3.1. Security Associations at the Initiator
The initiator of a base exchange defines its outbound SA as shown in
Table 6
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | The peer IP address from which R2 packet was |
| address | received during base exchange |
| UDP src port | Port 50500 |
| UDP dst port | Source port of incoming R2 packet during base |
| | exchange |
+--------------+----------------------------------------------------+
Table 6: Outbound SA at initiator
The initiator of a base exchange defines its inbound SA as shown in
Table 7
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The peer IP address from which R2 packet was |
| address | received during base exchange |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src port | Source port of incoming R2 packet during base |
| | exchange |
| UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+
Table 7: Inbound SA at initiator
3.4.3.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 8.
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | The peer IP as that used during base exchange |
| address | |
| UDP src port | The as source port chosen during base exchange |
| UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+
Table 8: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 9
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | Source peer IP address as used in base exchange |
| address | |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src port | Port 50500 |
| UDP dst port | The as source port chosen during base exchange |
+--------------+----------------------------------------------------+
Table 9: Inbound SA at responder
3.5. Both Hosts Behind NAT
This section describes the details of enabling NAT traversal for HIP
control and ESP data traffic, such as the base exchange
[I-D.ietf-hip-base], through UDP encapsulation, for the case when the
HIP initiator and the HIP responder are both behind two separate
NATs. The limitation of this approach is that the NAT middlebox MUST
support endpoint independent mapping
[I-D.srisuresh-behave-p2p-state].
The registration and rendezvous relay are handled similarly as
described in Section 3.3.3 and Section 3.4.1. Now that both hosts
are behind NATs, both the initiator (Section 3.3) and responder
(Section 3.4) mechanisms are combined here. There is one exception
though; the initiator does not retransmit an I1 but rather a NOTIFY
message.
3.5.1. NAT Traversal of HIP Control Traffic
Before an initiator can start the base exchange, the responder MUST
have completed a successful rendezvous client registration with its
RVS using the mechanism described in Section 3.4.1. The initiator of
the HIP base exchange starts the base exchange by sending a UDP
encapsulated I1 packet to RVS. The UDP packet MUST have destination
port number 50500 and the initiator is RECOMMENDED to use 50500 as
source port number. RVS MUST listen on UDP port 50500. RVS MUST
accept the packet as described in Section 3.3.3. As there has been a
successful rendezvous client registration between the responder and
the RVS as described in Section 3.4.1, the RVS knows the port number
to be used to communicate with the responder through the NAT. RVS
MUST add a FROM_NAT parameter to the I1 packet. The FROM_NAT
parameter contains the source address of the I1 packet, which is
effectively the address of the outermost NAT of the initiator. The
RVS copies the source port of the UDP encapsulated I1 packet into the
port number field of the FROM_NAT parameter. The FROM_NAT parameter
is integrity protected by an RVS_HMAC as described in
[I-D.ietf-hip-rvs]. It MUST replace the destination IP address of
the I1 packet by the one it had stored earlier during rendezvous
client registration. It MUST replace source IP address of I1 packet
with its own address. UDP source port of the relayed I1 packet MUST
be 50500 and destination port MUST be the same as one it had stored
during the client rendezvous registration. It MUST recompute the IP
header checksum.
Upon receiving the VIA_RVS_NAT parameter, the initiator sends NOTIFY
message without any contents to the responder, which responder MUST
ignore. This punches a hole to the NAT of the initiator.
The responder receives the I1 relayed by the RVS. The responder acts
as described in Section 3.4.2 by replying with an R1. The R1 punches
a hole to the responder's NAT for the initiator. The R1 makes it to
the initiator because the initiator already punched a hole in its own
NAT with the empty NOTIFY message for the responder.
The initiator and responder complete the rest of the base exchange
with I2 and R2. The NAT state may timeout in case the R1 cookie was
relatively large or in case the RTT is large. For this reason, the
initiator MUST refresh the state of the NATs by resending empty
NOTIFY messages until it receives an R2.
+---+ +----+ +-------+ +----+ +---+
| +--(1)-->| +---(2)-->+ | | | | |
| | | | | RVS-R | | | | |
| | | |<--(3a)--+ +---(3b)---->| | | |
| | | | +-------+ | | | |
| |<-(4a)--+ N | | N +--(4b)->| |
| | | A | | A | | |
| I +--(5a)->| T | | T |<-(5b)--+ R |
| | | - |<-(6b)------------------(6a)->| - | | |
| |<-(7b)--+ I | | R +--(7a)->| |
| | | | | | | |
| +--(8)-->| +--------------(9)------------>| +--(10)->| |
| | | | | | | |
| |<-(13)--+ |<-------------(12)------------+ |<-(11)--+ |
+---+ +----+ +----+ +---+
1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC)
4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500)
NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
4b. IP(IP-RVS, IP-R) UDP(50500, 50500)
I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC)
5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) NOTIFY(HIT-I, HIT-R)
5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111)
R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) NOTIFY(HIT-I, HIT-R)
6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111)
R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
7a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 50500) NOTIFY(HIT-I, HIT-R)
7b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 50500)
R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
8-10. I2(HIT-I, HIT-R), details similarly as in the cases before
11-13 R2(HIT-R, HIT-I), details similarly as in the cases before
Figure 10: UDP-encapsulated HIP base exchange (initiator and
responder behind a NAT, RVS on public IP).
The UDP hole punching is applicable only in the case when the NAT
devices on the path support address independent mapping
[I-D.srisuresh-behave-p2p-state]. After the initiator has received a
VIA_RVS_NAT parameter and has been in I1_SENT state for a policy
specific period, the initiator MAY transition to E-FAILED state.
Alternatively, it is RECOMMENED to switch to an external relay based
protocol mechanism.
3.5.2. NAT Traversal of HIP Data Traffic
After a successful base exchange, both the HIP nodes have all the
parameters with them to establish UDP BEET mode Security Association.
The following section describes inbound and outbound security
associations at initiator and responder.
3.5.2.1. Security Associations at the Initiator
The initiator of a base exchange defines its outbound SA as shown in
Table 10
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | The peer IP address from which R2 packet was |
| address | received during base exchange |
| UDP src port | The as the port number chosen to send I2 during |
| | base exchange |
| UDP dst port | Source port of incoming R2 packet during base |
| | exchange |
+--------------+----------------------------------------------------+
Table 10: Outbound SA at initiator
The initiator of a base exchange defines its inbound SA as shown in
Table 11
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The peer IP address from which R2 packet was |
| address | received during base exchange |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src port | Source port of incoming R2 packet during base |
| | exchange |
| UDP dst port | The as the port number chosen to send I2 during |
| | base exchange |
+--------------+----------------------------------------------------+
Table 11: Inbound SA at initiator
3.5.2.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 12.
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | The peer IP as that used during base exchange |
| address | |
| UDP src port | The as source port chosen send R2 during base |
| | exchange |
| UDP dst port | The as source port number of I2 packet during base |
| | exchange |
+--------------+----------------------------------------------------+
Table 12: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 13
+--------------+----------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------+
| Outer src | Source peer IP address as used in base exchange |
| address | |
| Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted |
| UDP src port | The as source Port received from I2 during base |
| | exchange |
| UDP dst port | The as source port used to send R2 during base |
| | exchange |
+--------------+----------------------------------------------------+
Table 13: Inbound SA at responder
3.6. NAT Keep-Alives
Typically, NATs cache an established binding and time it out if they
have not used it to relay traffic for a given period of time. This
timeout is different for different NAT implementations. The BEHAVE
working group is discussing recommendations for standardized timeout
values. To prevent NAT bindings that support the traversal of UDP-
encapsulated HIP traffic from timing out during times when there is
no control or data traffic, HIP hosts SHOULD send periodic keep-alive
messages.
Typically, only outgoing traffic refreshes the NAT port state for
security reasons. Consequently, both hosts SHOULD send periodic
keep-alives for the UDP channel of all their established HIP
associations if the channel has been idle for a specific period of
time.
For the UDP channel, keep-alives MUST be UDP-encapsulated HIP NOTIFY
packets as defined in Section 3.1.2. The packets MUST use the same
source and destination ports and IP addresses as the corresponding
UDP tunnel. The default keep-alive interval for control channels
SHOULD be 20 seconds. The peer host of the HIP association MUST
discard the keep-alives.
3.7. HIP Mobility
After a successful base exchange, a mobile node can change its
network location using the mechanisms defined in [I-D.ietf-hip-mm].
This section describes such mobility mechanisms in the presence of
NATs. However, the double jump scenario, where both peers move
simultaneously, is excluded.
The mobile node can change its location as described in Table 14.
+----+---------------------------+----------------------------------+
| No | From network | To network |
+----+---------------------------+----------------------------------+
| 1 | Behind NAT | Publicly Addressable Network |
| 2 | Publicly Addressable | Behind NAT |
| | Network | |
| 3 | Behind NAT-A | Stays behind NAT-A, but |
| | | different IP |
| 4 | Behind NAT-A | Behind NAT-B |
| 5 | Publicly Addressable | Publicly Addressable Network |
| | Network | |
+----+---------------------------+----------------------------------+
Table 14: End host mobility scenarios
The corresponding peer node can be located as follows Table 15
+----+------------------------------------------+
| No | Peer Node network |
+----+------------------------------------------+
| A | Publicly Addressable Network With RVS |
| B | Publicly Addressable Network Without RVS |
| C | Behind NAT With RVS |
| D | Behind NAT Without RVS |
+----+------------------------------------------+
Table 15: Peer host Network Scenarios
The NAT traversal mechanisms may not work when the corresponding node
is behind a NAT without RVS (case D), except when the mobile node
stays behind the same cone NAT (case 3D).
When a mobile node changes its location, it SHOULD detect the
presence of NATs along the new paths to its corresponding nodes using
some external mechanism before sending any UPDATE messages. If no
NAT was detected in such a case, it SHOULD send an UPDATE to its
corresponding nodes without UDP encapsulation.
The mobile node MUST send the UPDATE packet through the corresponding
node's RVS if it uses one, in addition to sending it to the
corresponding node directly. The mobile node encapsulates the UPDATE
packet within UDP only when it is behind a NAT. The corresponding
node MUST reply using UDP when the packet was encapsulated within
UDP, or without UDP when the UDP header was not present in the UPDATE
packet.
The rendezvous server relays the UPDATE similarly to I1. The
rendezvous server MUST add FROM parameter when it gets an UPDATE
packet without UDP encapsulation, or a FROM_NAT parameter when the
UPDATE packet it receives is UDP encapsulated and MUST in both cases
protect the packet with a HMAC parameter. Upon replying to the
UPDATE, the corresponding node MUST add a VIA_RVS (or VIA_RVS_NAT)
parameter to the reply.
The mobile node MUST leave out the NATted locators from the LOCATOR
parameter. This MUST be done before applying HMAC and SIGNATURE to
an R1, I2 or UPDATE packet. Thus, the LOCATOR parameter consists
only of the type and length fields when the mobile node has only
NATted addresses. When the mobile node has e.g. a single IPv6
address and one NATted address, the LOCATOR parameter consists of
single locator. The UDP header along with its port number conveys
the NATted locator to the peer.
3.8. HIP Multihoming
Multiple security associations can exists between the same hosts.
They may be connected through several paths, some of which may
include a NAT and others may not. Implementations that support
multihoming MUST support concurrent HIP associations between the same
host pair in a way that allows some of them to use UDP encapsulation
while others are not UDP encapsulated.
3.9. Firewall Traversal
When the initiator or the responder of a HIP association is behind a This section describes firewall traversal issues separately from NAT
firewall, additional issues arise. issues. When the Initiator or the Responder of a HIP association is
behind a firewall, additional issues arise.
When the initiator is behind a firewall, the NAT traversal mechanisms The NAT traversal mechanisms described in Section 3 require that the
described in Section 3 depend on the ability to initiate firewall - stateful or not - allows UDP traffic. At the minimum,
communication via UDP to destination port 50500 from arbitrary source successful firewall control packet traversal requires that the host
ports and to receive UDP response traffic from that port to the behind the firewall is allowed to communicate packets with a HIP
chosen source port. 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", Most firewall implementations support "UDP connection tracking",
i.e., after a host behind a firewall has initiated a UDP i.e., after a host behind a firewall has initiated UDP communication
communication to the public Internet, the firewall relays UDP to the public Internet, the firewall relays UDP response traffic in
response traffic in the return direction. If no such return traffic the return direction. If no such return traffic arrives for a
arrives for a specific period of time, the firewall stops relaying specific period of time, the firewall stops relaying the given IP
the given IP address and port pair. The mechanisms described in address and port pair. The mechanisms described in Section 3 already
Section 3 already enable traversal of such firewalls, if the keep- enable traversal of such firewalls, if the keep-alive interval used
alive interval used is less than the refresh interval of the is less than the refresh interval of the firewall.
firewall.
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 port 50500 and destined to arbitrary source
IP addresses and UDP ports.
When the responder is behind a firewall, the NAT traversal mechanisms When the Initiator is behind a firewall, the NAT traversal mechanisms
described in Section 3 depend on the ability to receive UDP traffic described in Section 3 depend on the ability to initiate
on port 50500 from arbitrary source IP addresses and ports. 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.
The NAT traversal mechanisms described in Section 3 require that the When the Responder is behind a firewall, the NAT traversal mechanisms
firewall - stateful or not - allow inbound UDP traffic to port 50500 described in Section 3 depend on the ability to send and receive UDP
and allow outbound UDP traffic to arbitrary UDP ports. If necessary traffic originating from HIPPORT of the HIP and ESP relays. When
for firewall traversal, ports reserved for IKE MAY be used for unrelayed traffic is preferred, arbitrary source IP addresses and
initiating new connections, but the implementation MUST be able to ports are required.
listen for UDP packets from port 50500.
4. Security Considerations 6. Security Considerations
4.1. A Difference to RFC3948 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 of 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 the 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 IPsec BEET
mode as described in Section 3, because the responder use the HITs to mode as described in Section 3, because the Responder use HITs to
distinguish between different communication instances. distinguish between different communication instances.
4.2. Rendezvous and Responder Privacy 6.2. Privacy Considerations
The rendezvous usage in this draft has been designed to follow the The LOCATORs are sent in plain text. Alternatively, they could be
RVS specification [I-D.ietf-hip-rvs] when the NAT supports end-point encrypted. This option was not chosen to allow packet inspection by
independent filtering. However, as NAT networking presents some middleboxes. Plain text locators may be useful for HIP-aware
additional challenges, it is not possible to follow the RVS design middleboxes in the future.
exactly. Particularly, the mechanisms described in Figure 7 and
Section 3.5.1 require that the rendezvous server replies back to the
initiator with a message which includes the address and port of the
responder NAT. Another design choice would have been to relay also
the R1 (and I2 in case of both hosts behind NAT) through the
rendezvous server to delay the exposure of the responder NAT address
and port related information for additional DoS protection. However,
this choice was not selected to reduce round trip time. As a
consequence, the rendezvous client must accept the risk of lowered
privacy protection when it registers to the RVS over UDP as defined
in Figure 8.
5. IANA Considerations 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
reveal the internal topology of the private address realm and it
discards unreflexive locators. Such behavior creates non-optimal
paths when the hosts are located behind the same NAT. Especially,
this could be a problem with a legacy NAT that does not support
routing from the private address realm back to itself through the
outer address of the NAT. This scenario is referred to as the
hairpin problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT,
the only option left would be to use a leased transport locator from
a relay. As a consequence, a host may support locator-based privacy
by leaving out the reflexive locators. Using only unreflexive
locators can produce suboptimal paths possibly causing congestion.
The use of relays can be useful for protection against Denial-of-
Service attacks. If a Responder reveals only its HIP and ESP relay
addresses to malign Initiators, the Initiators can only attack the
relays that does not prevent the Responder from initiating new
outgoing connections if a path around the relay exists.
6.3. Opportunistic Mode
The use of opportunistic HIP is NOT RECOMMENDED and its use is not
defined in this document. In opportunistic HIP, the Initiator sends
the I1 message with null destination HIT. Private address realms do
not have unique addresses by definition. Therefore, opportunistic
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
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" range, i.e., 50500. 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 50500 to the port IANA has registered. change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial
experimentation.
6. Acknowledgements This document updates the IANA Registry for HIP Parameters Types by
assigning new HIP Parameter Types values for the new HIP Parameters
defined in Section 4: o RELAY_FROM (defined in Section 4.3) o
RELAY_TO (defined in Section 4.3) o RELAY_VIA (defined in Section
4.3) o RELAY_HMAC (defined in Section 4.5)
The authors would like to thank Vivien Schmitt for his contributions 8. Acknowlegements
to previous versions of this draft. In addition, the authors would
like to thank Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. The authors would like to thank Lars Eggert, Vivien Schmitt, Abhinav
Ahrenholz, Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka Pathak and Andrei Gurtov for their contributions to previous versions
Nikander, Lauri Silvennoinen, Jukka Ylitalo, Andrei Gurtov and Juha of this draft. Thanks for Philip Matthews on introducing ICE
Heinanen for their comments on this document. 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 [I-D.nikander-hip-path] presented some initial ideas for NAT
traversal of HIP communication. This document describes traversal of HIP communication. The idea was based on NAT detection
significantly different mechanisms that, among other differences, use using extra parameters in the base exchange. This document takes a
external NAT discovery and do not require encapsulation servers. different approach based on ICE.
Simon Schuetz and Martin Stiemerling are partly funded by Ambient Simon Schuetz and Martin Stiemerling are partly funded by Ambient
Networks, a research project supported by the European Commission Networks, a research project supported by the European Commission
under its Sixth Framework Program. The views and conclusions under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission. project or the European Commission.
Miika Komu is working for InfraHIP research group at Helsinki Miika Komu is working in the Networking Research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project is Institute for Information Technology (HIIT). The InfraHIP project
funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
Ericsson. Forces and Ericsson. Miika Komu wrote draft-ietf-hip-nat-02 version
from scratch based on ICE-related comments from Philip Matthews.
7. References 9. References
7.1. Normative References 9.1. Normative References
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006. draft-ietf-hip-base-08 (work in progress), June 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-04 (work in progress), October 2006. draft-ietf-hip-esp-06 (work in progress), June 2007.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-04 (work in Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007.
[I-D.ietf-hip-registration]
Laganier, J., "Host Identity Protocol (HIP) Registration
Extension", draft-ietf-hip-registration-02 (work in
progress), June 2006. progress), June 2006.
[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]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007.
[I-D.nikander-esp-beet-mode] [I-D.nikander-esp-beet-mode]
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-06 (BEET) mode for ESP", draft-nikander-esp-beet-mode-07
(work in progress), August 2006. (work in progress), February 2007.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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.
[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.
7.2. Informative References 9.2. Informative References
[I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-00
(work in progress), February 2007.
[I-D.ietf-behave-nat-udp] [I-D.ietf-behave-p2p-state]
Audet, F. and C. Jennings, "NAT Behavioral Requirements Srisuresh, P., "State of Peer-to-Peer(P2P) Communication
for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in Across Network Address Translators(NATs)",
progress), October 2006. draft-ietf-behave-p2p-state-03 (work in progress),
July 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-03 (work in progress), June 2006. draft-irtf-hiprg-nat-04 (work in progress), March 2007.
[I-D.nikander-hip-path] [I-D.nikander-hip-path]
Nikander, P., "Preferred Alternatives for Tunnelling HIP Nikander, P., "Preferred Alternatives for Tunnelling HIP
(PATH)", draft-nikander-hip-path-01 (work in progress), (PATH)", draft-nikander-hip-path-01 (work in progress),
March 2006. March 2006.
[I-D.srisuresh-behave-p2p-state] [I-D.oliva-hiprg-reap4hip]
Srisuresh, P., "State of Peer-to-Peer(P2P) Communication Oliva, A. and M. Bagnulo, "Fault tolerance configurations
Across Network Address Translators(NATs)", for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work
draft-srisuresh-behave-p2p-state-04 (work in progress), in progress), July 2007.
September 2006.
[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.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[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.
Appendix A. Document Revision History [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Appendix A. Differences to ICE
The protocol extensions defined in this draft are based on ICE. The
extensions are a rough translation of ICE concepts to HIP protocol.
The translation preserved certain concepts as they are, but there are
subtle differences. This section tries to explain how ICE concepts
were mapped to HIP protocol and what are the differences.
The terminology for this draft is a hybrid of ICE and HIP
terminology. "Agent" was translated to "host" in favour of HIP
terminology. Transport address was changed to transport locator.
Similarly, address pair is denoted as locator pair. This document
does not really talk about "candidate addresses", but just "locators"
which may or may not be verified using the return routability tests,
in favour of mobility terminology in [I-D.ietf-hip-mm]. Host
candidate of ICE became unreflexive locator, server reflexive
candidate was mapped to relay reflexive transport locator, peer
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
as there is only a single "media stream" for all (ESP) traffic
between two hosts.
There is no "lite" version ICE in this document, just full, as the
full version is the preferred one also for ICE. One specific
scenario defined in this document has some resemblance to the lite
ICE. When a Responder is a publicly accessible server with fixed
address, it may exclude the use of the relay. In that case, it does
not have to handle the RELAY parameters but still has to respond to
the connectivity checks.
A connectivity check is not a STUN Binding Request. Instead, it is
return routability check as defined in [I-D.ietf-hip-mm]. "Triggered
check" occurs when a host receives a UPDATE with ECHO_REQUEST and it
responds using a ECHO_RESPONSE and sends its own ECHO_REQUEST. A
"check list" is effectively a LOCATOR parameter as defined in
[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
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
has built-in security mechanisms that preferred over the ones that
are used in ICE.
Appendix B. Document Revision History
To be removed upon publication To be removed upon publication
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| schmitt-00 | Initial version. | | schmitt-00 | Initial version. |
| ietf-00 | Officially adopted as WG item. Solved issues | | ietf-00 | Officially adopted as WG item. Solved issues |
| | 1-9,11,12 | | | 1-9,11,12 |
| ietf-01 | Solved remaining issues except that relaying ESP and |
| | mobility were still incomplete. |
| 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 (editor)
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Tammasaarenkatu 3 Metsanneidonkuja 4
Helsinki 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 Simon Schuetz
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 4342 165 Phone: +49 6221 4342 165
Fax: +49 6221 4342 155 Fax: +49 6221 4342 155
Email: simon.schuetz@netlab.nec.de Email: simon.schuetz@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
skipping to change at page 34, line 4 skipping to change at page 30, line 14
Simon Schuetz Simon Schuetz
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 4342 165 Phone: +49 6221 4342 165
Fax: +49 6221 4342 155 Fax: +49 6221 4342 155
Email: simon.schuetz@netlab.nec.de Email: simon.schuetz@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Martin Stiemerling Martin Stiemerling
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 4342 113 Phone: +49 6221 4342 113
Fax: +49 6221 4342 155 Fax: +49 6221 4342 155
Email: stiemerling@netlab.nec.de Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Lars Eggert
Nokia Research Center
P.O. Box 407
Nokia Group 00045
Finland
Phone: +358 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Abhinav Pathak
IIT Kanpur
B204, Hall - 1, IIT Kanpur
Kanpur 208016
India
Phone: +91 9336 20 1002
Email: abhinav.pathak@hiit.fi
URI: http://www.iitk.ac.in/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
 End of changes. 105 change blocks. 
1201 lines changed or deleted 1040 lines changed or added

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