draft-ietf-hip-nat-traversal-04.txt   draft-ietf-hip-nat-traversal-05.txt 
HIP Working Group M. Komu HIP Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Experimental T. Henderson Intended status: Experimental T. Henderson
Expires: January 16, 2009 The Boeing Company Expires: May 4, 2009 The Boeing Company
P. Matthews P. Matthews
(Unaffiliated) (Unaffiliated)
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
A. Keraenen, Ed. A. Keranen, Ed.
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
July 15, 2008 October 31, 2008
Basic HIP Extensions for Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-04.txt draft-ietf-hip-nat-traversal-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2009. This Internet-Draft will expire on May 4, 2009.
Abstract Abstract
The Host Identity Protocol (HIP) provides a new namespace that can be This document specifies extensions to the Host Identity Protocol
used for uniquely identifying hosts. Existing HIP experimental (HIP) to facilitate Network Address Translator (NAT) traversal. The
specifications do not specify protocol operations across Network extensions are based on the use of the Interactive Connectivity
Address Translators (NATs). Establishment (ICE) methodology to discover a working path between
two end-hosts, and on standard techniques for encapsulating
This document specifies basic NAT traversal extensions for HIP. The Encapsulating Security Payload (ESP) packets within the User Datagram
HIP shim layer is located between the network and transport layer, Protocol (UDP). This document also defines elements of procedure for
the extensions can also provide a more general-purpose NAT traversal NAT traversal, including the optional use of a HIP relay server.
support for higher-layer networking applications. The extensions are With these extensions HIP is able to work in environments that have
based on the use of the The Interactive Connectivity Establishment NATs and provides a generic NAT traversal solution to higher-layer
(ICE) methodology to discover a working path between two end-hosts. networking applications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
3.2. NAT Transformation Negotiation . . . . . . . . . . . . . . 8 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8
3.3. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10
3.4. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 11 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10
3.5. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12
3.6. Base Exchange without ICE Connectivity Checks . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12
3.7. Base Exchange without UDP Encapsulation . . . . . . . . . 13 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 14
3.8. Sending Control Messages using the Data Plane . . . . . . 13 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16
4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 14 4.9. Simultaneous Base Exchange with and without UDP
4.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 14 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 15 4.10. Sending Control Messages after the Base Exchange . . . . . 17
4.4. Relay and Registration Parameters . . . . . . . . . . . . 16 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 17 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18
4.6. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 18
4.7. Registration Types . . . . . . . . . . . . . . . . . . . . 19 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 20 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 5.6. Relay and Registration Parameters . . . . . . . . . . . . 21
5.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 21 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22
5.3. Base Exchange Replay Protection for HIP Relay Server . . . 21 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 23
5.4. Demuxing Different HIP Associations . . . . . . . . . . . 21 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.10. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 24
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 25
Appendix A. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Base Exchange through a Rendezvous Server . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Document Revision History . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28
Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 29
Appendix C. Base Exchange through a Rendezvous Server . . . . . . 29
Appendix D. Document Revision History . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
HIP [RFC5201] is defined as a protocol that runs directly over IPv4 HIP [RFC5201] is defined as a protocol that runs directly over IPv4
or IPv6. This approach is known to have problems traversing NATs. A or IPv6, and HIP coordinates the setup of ESP security associations
detailed description of HIP problems with traversing legacy [RFC5202] that are also specified to run over IPv4 or IPv6. This
middleboxes is documented in [I-D.irtf-hiprg-nat]. This document approach is known to have problems traversing NATs and other
describes HIP extensions for the traversal of both Network Address middleboxes [RFC5207]. This document defines HIP extensions for the
Translator (NAT) and Network Address and Port Translator (NAPT) traversal of both Network Address Translator (NAT) and Network
middleboxes. The document generally uses the term NAT to refer to Address and Port Translator (NAPT) middleboxes. The document
these types of middleboxes. generally uses the term NAT to refer to these types of middleboxes.
Currently deployed NAT devices do not operate consistently even Currently deployed NAT devices do not operate consistently even
though a recommended behavior is described in [RFC4787]. The HIP though a recommended behavior is described in [RFC4787]. The HIP
protocol extensions in this document make as few assumptions as protocol extensions in this document make as few assumptions as
possible about the behavior of the NAT devices so that NAT traversal possible about the behavior of the NAT devices so that NAT traversal
will work even with legacy NAT devices. The purpose of these will work even with legacy NAT devices. The purpose of these
extensions is to allow two HIP-enabled hosts to communicate with each extensions is to allow two HIP-enabled hosts to communicate with each
other even if one or both communicating hosts are in private address other even if one or both of the communicating hosts are in a network
realms. that is behind one or more NATs.
Using the extensions defined in this draft, HIP end-hosts use the HIP Using the extensions defined in this document, HIP end-hosts use
control channel to communicate their current locators to each other techniques drawn from the Interactive Connectivity Establishment
to find a operational path for the ESP encapsulated data traffic. (ICE) methodology [I-D.ietf-mmusic-ice] to find operational paths for
The hosts test connectivity between different locators and try to the HIP control protocol and for ESP encapsulated data traffic. The
discover direct end-to-end path between the end-hosts. However, With hosts test connectivity between different locators and try to
some legacy NATs, utilizing the shortest path between two end hosts discover a direct end-to-end path between them. However, with some
legacy NATs, utilizing the shortest path between two end-hosts
located behind NATs is not possible without relaying the traffic located behind NATs is not possible without relaying the traffic
through a relay, such as a TURN server [RFC5128]. As a consequence, through a relay, such as a TURN server [RFC5128]. Because relaying
the TURN server increases the roundtrip delay and may become a point traffic increases the roundtrip delay and consumes resources from the
of network congestion. With the extensions described in this relay, with the extensions described in this document, hosts try to
document, hosts try to avoid the use the TURN server when possible. avoid using the TURN server whenever possible.
This document defines new middlebox extensions to allow NAT traversal
for HIP control plane. The HIP Relay extensions define mechanisms to
forward HIP control plane. A distinction must be made here between a
HIP rendezvous services [RFC5204]) and HIP Relay services. HIP
rendezvous servers solve initial contact and mobility related
problems in networks without NATs. HIP Relay servers solve the same
problems, in addition to NAT traversal problems. HIP Relay servers
can be used both in NATed and non-NATed networks.
Both rendezvous and relay services forward HIP control packets, but HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP
the main difference is that the rendezvous service forwards only the hosts to establish a stable point-of-contact in the Internet. This
initial I1 packet of the base exchange while all other HIP control document defines extensions to the Rendezvous Server that solve the
packets are sent directly between the communicating hosts. In same problems but for both NATed and non-NATed networks. The
contrast, the relay service relays all HIP control packets because extended Rendezvous Server, called a "HIP relay server," forwards all
NATs can drop the packets otherwise [RFC5128]. HIP control packets between an Initiator and Responder, allowing
Responders to be located behind NATs. This behavior is in contrast
to the HIP rendezvous service that forwards only the initial I1
packet of the base exchange, which is less likely to work in a NATed
environment [RFC5128]. Therefore, when using relays to traverse
NATs, HIP uses a HIP relay server for the control traffic and a TURN
server for the data traffic.
The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice].
[I-D.ietf-mmusic-ice] describes ICE as follows: [I-D.ietf-mmusic-ice] describes ICE as follows:
"The Interactive Connectivity Establishment (ICE) methodology is a "The Interactive Connectivity Establishment (ICE) methodology is a
technique for NAT traversal for UDP-based media streams (though technique for NAT traversal for UDP-based media streams (though
ICE can be extended to handle other transport protocols, such as ICE can be extended to handle other transport protocols, such as
TCP) established by the offer/answer model. ICE is an extension TCP) established by the offer/answer model. ICE is an extension
to the offer/answer model, and works by including a multiplicity to the offer/answer model, and works by including a multiplicity
of IP addresses and ports in SDP offers and answers, which are of IP addresses and ports in SDP offers and answers, which are
then tested for connectivity by peer-to-peer connectivity checks. then tested for connectivity by peer-to-peer connectivity checks.
The IP addresses and ports included in the SDP and the The IP addresses and ports included in the SDP and the
skipping to change at page 4, line 18 skipping to change at page 5, line 14
"The Interactive Connectivity Establishment (ICE) methodology is a "The Interactive Connectivity Establishment (ICE) methodology is a
technique for NAT traversal for UDP-based media streams (though technique for NAT traversal for UDP-based media streams (though
ICE can be extended to handle other transport protocols, such as ICE can be extended to handle other transport protocols, such as
TCP) established by the offer/answer model. ICE is an extension TCP) established by the offer/answer model. ICE is an extension
to the offer/answer model, and works by including a multiplicity to the offer/answer model, and works by including a multiplicity
of IP addresses and ports in SDP offers and answers, which are of IP addresses and ports in SDP offers and answers, which are
then tested for connectivity by peer-to-peer connectivity checks. then tested for connectivity by peer-to-peer connectivity checks.
The IP addresses and ports included in the SDP and the The IP addresses and ports included in the SDP and the
connectivity checks are performed using the revised STUN connectivity checks are performed using the revised STUN
specification [I-D.ietf-behave-rfc3489bis], now renamed to Session specification [RFC5389], now renamed to Session Traversal
Traversal Utilities for NAT." Utilities for NAT."
ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP The standard ICE [I-D.ietf-mmusic-ice] is specified with SIP in mind
protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip]. and it has some features that are not necessary or suitable as such
for other protocols. [I-D.rosenberg-mmusic-ice-nonsip] gives
instructions and recommendations on how ICE can be used for other
protocols and this document follows those guidelines.
Two hosts communicate their locators to each other in the HIP base Two HIP hosts that implement this specification communicate their
exchange. They are then paired with the locally operational address locators to each other in the HIP base exchange. The locators are
of the other endpoint and prioritized according local and recommended then paired with the locators of the other endpoint and prioritized
policies. These address sets are then tested sequentially based on according to recommended and local policies. These locator pairs are
the procedures specified in ICE. Both sides participate in the then tested sequentially by both of the end hosts. The tests may
connectivity checks. The tests may also discover multiple result in multiple operational pairs but ICE procedures determine a
operational address pairs but determine a single preferred address single preferred address pair to be used for subsequent
pair to be used for subsequent communication. communication.
In a nutshell, the extensions in this document defines: In summary, the extensions in this document define:
o encapsulatation of HIP packets in UDP o UDP encapsulation of HIP packets
o UDP encapsulation of IPsec ESP packets o UDP encapsulation of IPsec ESP packets
o registration extensions for HIP Relay services o registration extensions for HIP relay services
o how the "offer" and "answer" are carried in the base exchange o how the ICE "offer" and "answer" are carried in the base exchange
o interaction with ICE connectivity messages o interaction with ICE connectivity check messages
o backwards compatibility issues with rendezvous servers o backwards compatibility issues with rendezvous servers
o a number of optimizations (such when the ICE connectivity tests o a number of optimizations (such as when the ICE connectivity tests
can be excluded) can be omitted)
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [RFC5201], [RFC5206], This document borrows terminology from [RFC5201], [RFC5206],
[RFC4423], [I-D.ietf-mmusic-ice], and [I-D.ietf-behave-rfc3489bis]. [RFC4423], [I-D.ietf-mmusic-ice], and [RFC5389]. Additionally, the
Additionally, the following terms are used: following terms are used:
Rendezvous server: Rendezvous server:
A host that forwards I1 packets to the Responder.
A host that forwards I1 packets to the Responder HIP relay server:
A host that forwards all HIP control packets between the Initiator
HIP Relay: and the Responder.
A host that forwards all HIP control packets between an Initiator
and Responder
TURN server: TURN server:
A server that forwards data traffic between two end-hosts as
A server that forwards data traffic between two end-hosts defined in [I-D.ietf-behave-turn].
Locator: Locator:
As defined in [RFC5206]: "A name that controls how the packet is As defined in [RFC5206]: "A name that controls how the packet is
routed through the network and demultiplexed by the end host. It routed through the network and demultiplexed by the end-host. It
may include a concatenation of traditional network addresses such may include a concatenation of traditional network addresses such
as an IPv6 address and end-to-end identifiers such as an ESP SPI. as an IPv6 address and end-to-end identifiers such as an ESP SPI.
It may also include transport port numbers or IPv6 Flow Labels as It may also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address." demultiplexing context, or it may simply be a network address."
It should noticed that "address" is used in this document as a It should noted that "address" is used in this document as a
synonym for locator. synonym for locator.
HIP Relay: LOCATOR (written in capital letters):
Denotes a HIP control message parameter that bundles multiple
LOCATOR (written in capital letters) denotes a HIP control message locators together.
parameter that bundles multiple locators together
ICE Offer:
The Initiator's LOCATOR parameter in HIP I2 control message.
ICE Answer: ICE offer:
The Initiator's LOCATOR parameter in a HIP I2 control message.
The Responder's LOCATOR parameter in HIP R2 control message ICE answer:
The Responder's LOCATOR parameter in a HIP R2 control message.
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address.
Transport layer port and the corresponding IPv4/v6 address
Candidate: Candidate:
A transport address that is a potential point of contact for
A transport address that has not been verified yet for receiving data.
reachability using ICE
Host candidate: Host candidate:
A candidate obtained by binding to a specific port from an IP
address on the host.
An IPv4 or IPv6 address of a network interface of a host Server reflexive candidate:
A translated transport address of a host as observed by a HIP
relay server or a STUN/TURN server.
Server reflexive transport candidate: Peer reflexive candidate:
A translated transport address of a host as observed by its peer.
A translated transport address of a host as observed by a HIP Relayed candidate:
Relay or a STUN server A transport address that exists on a TURN server. Packets that
arrive at this address are relayed towards the TURN client.
Peer reflexive transport candidate: 3. Overview of Operation
A translated transport address of a host as observed by its peer +-------+
| HIP |
+--------+ | Relay | +--------+
| TURN | +-------+ | STUN |
| Server | / \ | Server |
+--------+ / \ +--------+
/ \
/ \
/ \
/ <- Signaling -> \
/ \
+-------+ +-------+
| NAT | | NAT |
+-------+ +-------+
/ \
/ \
+-------+ +-------+
| Init- | | Resp- |
| iator | | onder |
+-------+ +-------+
Relayed transport candidate: Figure 1: Example network configuration
A transport address that exists on a TURN server. Packets that In an example configuration depicted in Figure 1, both Initiator and
arrive at this address are relayed towards the TURN client. Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT,
the Responder must be registered with a HIP relay server reachable on
the public Internet, and we assume as a starting point that the
Initiator knows both the Responder's HIT and the address of one of
its relay servers (how the Initiator learns of the Responder's relay
server is outside of the scope of this document, but may be through
DNS or another name service).
3. Protocol Description The first steps are for both the Initiator and Responder to register
with a relay server (need not be the same one) and gather a set of
address candidates. Next, the HIP base exchange is carried out by
encapsulating the HIP control packets in UDP datagrams and sending
them through the Responder's relay server. As part of the base
exchange, each HIP host learns of the peer's candidate addresses
through the ICE offer/answer procedure embedded in the base exchange.
Once the base exchange is completed, HIP has established a working
communication session (for signaling) via a relay server, but the
hosts still work to find a better path, preferably without a relay,
for the ESP data flow. For this, ICE connectivity checks are carried
out until a working pair of addresses is discovered. At the end of
the procedure, if successful, the hosts will have enabled a UDP-based
flow that traverses both NATs, with the data flowing directly from
NAT to NAT or via a TURN server. Further HIP signaling can be sent
over the same address/port pair and is demultiplexed from data
traffic via a marker in the payload. Finally, NAT keepalives will be
sent as needed.
If either one of the hosts knows that it is not behind a NAT, hosts
can negotiate during the base exchange a different mode of NAT
traversal that does not use ICE connectivity checks, but only UDP
encapsulation of HIP and ESP. Also, it is possible for the Initiator
to simultaneously try a base exchange with and without UDP
encapsulation. If a base exchange without UDP encapsulation
succeeds, no ICE connectivity checks or UDP encapsulation of ESP are
needed.
4. Protocol Description
This section describes the normative behavior of the protocol This section describes the normative behavior of the protocol
extension. Examples of packet exchanges are provided for extension. Examples of packet exchanges are provided for
illustration purposes. illustration purposes.
3.1. Relay Registration 4.1. Relay Registration
HIP rendezvous servers operate in non-NATed environments and their HIP rendezvous servers operate in non-NATed environments and their
use is described in [RFC5204]. This section specifies a new use is described in [RFC5204]. This section specifies a new
middlebox extension, called the HIP Relay, to perate in NATted middlebox extension, called the HIP relay server, for operating in
environments. HIP Relay servers forward all HIP control packets NATed environments. A HIP relay server forwards all HIP control
between the Initiator and the Responder over UDP. packets between the Initiator and the Responder.
End-hosts cannot use the HIP Relay service for forward ESP data End-hosts cannot use the HIP relay service for forwarding the ESP
plane. Instead, they use TURN servers [I-D.ietf-behave-turn] for data plane. Instead, they use TURN servers [I-D.ietf-behave-turn]
relaying the ESP traffic. A HIP end-host SHOULD register to a TURN for that.
server before registering to a HIP Relay to guarantee that the host
can accept ESP traffic immediately after HIP Relay registration.
A HIP Relay MUST silently drop packets to a HIP Relay Client that has A HIP relay server MUST silently drop packets to a HIP relay client
not previously registered with the HIP Relay. The registration that has not previously registered with the HIP relay. The
process follows the generic registration extensions defined in registration process follows the generic registration extensions
[RFC5203] and is illustrated in Figure 1. defined in [RFC5203] and is illustrated in Figure 2.
HIP HIP HIP HIP
Relay Relay Relay Relay
Client Server Client Server
| 1. UDP(I1) | | 1. UDP(I1) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
| | | |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
Figure 1: Example Registration to a HIP Relay Figure 2: Example Registration to a HIP Relay
In step 1, the Relay Client (Initiator) starts the registration In step 1, the relay client (Initiator) starts the registration
procedure by sending an I1 packet over UDP. It is RECOMMENDED that procedure by sending an I1 packet over UDP. It is RECOMMENDED that
the Initiator selects a random port number from the ephemeral port the Initiator selects a random port number from the ephemeral port
range 49152-65535 for initiating a base exchange. However, the range 49152-65535 for initiating a base exchange. However, the
allocated port MUST be maintained until all of the corresponding HIP allocated port MUST be maintained until all of the corresponding HIP
Associations are closed. Alternatively, a host MAY also use a single Associations are closed. Alternatively, a host MAY also use a single
fixed port for initiating all outgoing connections. fixed port for initiating all outgoing connections. The HIP relay
server MUST listen to incoming connections at UDP port HIPPORT.
In step 2, the Relay Server (Responder) lists the services that it In step 2, the HIP relay server (Responder) lists the services that
supports in the R1 packet. The support for HIP-over-UDP relaying is it supports in the R1 packet. The support for HIP-over-UDP relaying
denoted by the RELAY_UDP_HIP value. The R1 SHOULD not contain any is denoted by the RELAY_UDP_HIP value.
NAT transform parameter.
In step 3, the Initiator selects the services it registers for and In step 3, the Initiator selects the services it registers for and
lists them in the REG_REQ parameter. In this example, the Initiator lists them in the REG_REQ parameter. The Initiator registers for HIP
registers for HIP Relay service. relay service by listing the RELAY_UDP_HIP value in the request
parameter.
In step 4, the Responder concludes the registration procedure with an In step 4, the Responder concludes the registration procedure with an
R2 packet and acknowledges the registered services in the REG_RES R2 packet and acknowledges the registered services in the REG_RES
parameter. The Responder denotes unsuccessful registrations in the parameter. The Responder denotes unsuccessful registrations (if any)
REG_FAILED parameter in R2. The Responder also includes a REG_FROM in the REG_FAILED parameter of R2. The Responder also includes a
parameter that contains the transport address of the client as REG_FROM parameter that contains the transport address of the client
observed by the Relay (Server Reflexive candidate). After the as observed by the relay (Server Reflexive candidate). After the
registration, the Initiator sends periodically NAT keepalives. registration, the client sends NAT keepalives periodically to the
relay to keep possible NAT bindings between the client and the relay
alive.
There are different ways for an Initiator to learn it's publicly 4.2. ICE Candidate Gathering
visible IP address and port that are referred to as the "server
reflexive transport candidate" in this document. It is a local
decision on how the end-host learnds the candidate, but either of the
following methods is RECOMMENDED:
o The Relay client may use STUN servers to detect the server If a host is going to use ICE, it needs to gather a set of address
reflexive locator, as described in [RFC5128]. candidates. The candidate gathering SHOULD be done as defined in
Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered
for only one media stream and component. Component ID 1 should be
used for ICE processing, where needed. Initiator takes the role of
the ICE controlling agent.
o Alternatively, the Relay Client can learn it from the REG_FROM The candidate gathering can be done at any time, but it needs to be
parameter when registering to a Relay. done before sending an I2 or R2 if ICE is used for the connectivity
checks. It is RECOMMENDED that all three types of candidates (host,
server reflexive and relayed) are gathered to maximize probability of
successful NAT traversal. However, if no TURN server is used, and
the host has only a single local IP address to use, the host MAY use
the local address as the only host candidate and the address from the
REG_FROM parameter discovered during the relay registration as a
server reflexive candidate. In this case, no further candidate
gathering is needed.
3.2. NAT Transformation Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical transform This section describes the usage of a new non-critical parameter
parameter type. The presence of the parameter in HIP base exchange type. The presence of the parameter in a HIP base exchange means
means that the end-host supports ICE connectivity checks. As the that the end-host supports NAT traversal extensions described in this
parameter is non-critical, it can be ignored by an end-host which document. As the parameter is non-critical, it can be ignored by an
means that the host does not support or is not willing to use ICE end-host which means that the host does not support or is not willing
connectivity checks. to use these extensions.
The NAT transform parameter applies to a base exchange between end- The NAT traversal mode parameter applies to a base exchange between
hosts, but currently does not apply to with a registration with a HIP end-hosts, but currently does not apply to a registration with a HIP
Relay server. The NAT transform applies only to a base exchange with relay server. The NAT traversal mode negotiation in base exchange is
transport layer encapsulation and MUST not be included without illustrated in Figure 3.
transport layer encapsulation. The NAT transform negotiation in base
exchange is illustrated in Figure 2.
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+------------------------------------------------------------->| +------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<-------------------------------------------------------------+ |<-------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) |
+------------------------------------------------------------->| +------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., LOCATOR, ..)) | | 4. UDP(R2(.., LOCATOR, ..)) |
|<-------------------------------------------------------------+ |<-------------------------------------------------------------+
| .... | | .... |
Figure 2: Negotiation of NAT Transforms Figure 3: Negotiation of NAT Traversal Mode
In step 1, the Initiator sends an I1 to the Responder. In step 2, In step 1, the Initiator sends an I1 to the Responder. In step 2,
the Responder responds with an R1. The R1 contains a list of the Responder responds with an R1. The R1 contains a list of NAT
transforms the Responder supports in NAT_TRANSFORM parameter as shown traversal modes the Responder supports in the NAT_TRAVERSAL_MODE
in Table 1. parameter as shown in Table 1.
+--------------+----------------------------------------------------+ +-------------------+-----------------------------------------------+
| Transform | Purpose | | Type | Purpose |
| Type | | +-------------------+-----------------------------------------------+
+--------------+----------------------------------------------------+
| RESERVED | Reserved for future use | | RESERVED | Reserved for future use |
| ICE-STUN-UDP | UDP encapsulated control and data traffic with | | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP |
| | ICE-based connectivity checks using STUN messages | | | signaling traffic and ESP (no ICE |
+--------------+----------------------------------------------------+ | | connectivity checks) |
| ICE-STUN-UDP | UDP encapsulated control and data traffic |
| | with ICE-based connectivity checks using STUN |
| | messages |
+-------------------+-----------------------------------------------+
Table 1: Locator Transformations Table 1: NAT Traversal Modes
In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM In step 3, the Initiator sends an I2 that includes a
parameter. It contains the transform type selected by the Initiator NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
from the list of transforms offered by the Responder. The I2 also Initiator from the list of modes offered by the Responder. The I2
includes the locators of the Initiator in a LOCATOR parameter. The also includes the locators of the Initiator in a LOCATOR parameter.
locator parameter in I2 is the "ICE offer". The locator parameter in I2 is the "ICE offer".
In step 4, the Responder concludes the base exchange with an R2 In step 4, the Responder concludes the base exchange with an R2
packet. The Responder includes a LOCATOR parameter in the R2 packet. packet. The Responder includes a LOCATOR parameter in the R2 packet.
The locators parameter in R2 is the "ICE answer". The locator parameter in R2 is the "ICE answer".
3.3. Base Exchange via HIP Relay 4.4. Connectivity Check Pacing Negotiation
This section describes how Initiator and Responder establish a base As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with
exchange through a HIP Relay. The NAT transform negotiation (denoted connectivity checks is used, new transactions should not be started
as NAT_TFM in the example) was described in previous section and too fast to avoid congestion and overwhelming the NATs.
shall not be repeated here. When a Relay receives an R1 or I2 packet
without the NAT transform packet, it drops it and sends a NOTIFY For this purpose, during the base exchange, hosts can negotiate a
error message to the originator. transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
I2 and R2 messages. The parameter contains the minimum time
(expressed in milliseconds) the host would wait between two NAT
traversal transactions, such as starting a new connectivity check or
retrying a previous check. If a host does not include this parameter
in the base exchange, a Ta value of 500ms MUST be used as that host's
minimum value. The value that is used by both of the hosts is the
higher out of the two offered values.
Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta,
since such values may not work well with some NATs, as explained in
[I-D.ietf-mmusic-ice].
The minimum Ta value SHOULD be configurable. Guidelines for
selecting a Ta value are given in Appendix A. Currently this feature
applies only to the ICE-STUN-UDP NAT traversal mode.
4.5. Base Exchange via HIP Relay Server
This section describes how Initiator and Responder perform a base
exchange through a HIP relay server. The NAT traversal mode
negotiation (denoted as NAT_TM in the example) was described in the
previous section and shall not be repeated here. If a relay receives
an R1 or I2 packet without the NAT traversal mode parameter, it drops
it and sends a NOTIFY error message to the sender of the R1/I2.
It is RECOMMENDED that the Initiator sends an I1 packet encapsulated It is RECOMMENDED that the Initiator sends an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with an Respectively, the Responder MUST respond to such an I1 packet with an
R1 packet over the transport layer and using the same transport R1 packet over the transport layer and using the same transport
protocol. The rest of the base exchange, I2 and R2, MUST also use protocol. The rest of the base exchange, I2 and R2, MUST also use
the same transport layer. the same transport protocol.
I HIP Relay R I HIP relay R
| 1. UDP(I1) | | | 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) | +----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TFM)) | | | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO),NAT_TFM) |<-------------------------------+ | 4. UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
| 5. UDP(I2(LOCATOR),NAT_TFM) | | | 5. UDP(I2(LOCATOR),NAT_TM) | |
+----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),| +----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),|
| | NAT_TFM) | | | NAT_TM) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(LOCATOR,RELAY_TO)) | | | 7. UDP(R2(LOCATOR,RELAY_TO)) |
| 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
Figure 3: Base Exchange via a HIP Relay Figure 4: Base Exchange via a HIP Relay Server
In step 1 of Figure 3, the Initiator sends an I1 packet over the In step 1 of Figure 4, the Initiator sends an I1 packet over the
transport layer to the HIT of the Responder. The source address is transport layer to the HIT of the Responder (and IP address of the
one of the locators of the host. The locators belonging to the end- relay). The source address is one of the locators of the Initiator.
hosts are referred as "host candidates" in this document.
In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If In step 2, the HIP relay server receives the I1 packet at port
the destination HIT belongs to a registered Responder, the Relay HIPPORT. If the destination HIT belongs to a registered Responder,
processes the packet. Otherwise, the Relay MUST drop the packet the relay processes the packet. Otherwise, the relay MUST drop the
silently. The Relay appends a RELAY_FROM parameter to the I1 packet packet silently. The relay appends a RELAY_FROM parameter to the I1
which contains the transport source address and port of the I1 as packet which contains the transport source address and port of the I1
observed by the Relay. The Relay protects the I1 packet with as observed by the relay. The relay protects the I1 packet with
RELAY_HMAC as described in [RFC5204], except that the parameter type RELAY_HMAC as described in [RFC5204], except that the parameter type
is different. The Relay changes the source and destination ports and is different (see Section 5.8). The relay changes the source and
IP addresses of the packet to match the values the Responder used destination ports and IP addresses of the packet to match the values
when registering to the Relay, i.e., the reverse of the R2 used in the Responder used when registering to the relay, i.e., the reverse
the registration. The Relay MUST recalculate the transport checksum of the R2 used in the registration. The relay MUST recalculate the
and forward the packet to the Responder. transport checksum and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [RFC5201]. In addition, the processes it according to the rules in [RFC5201]. In addition, the
Responder validates the RELAY_HMAC according to [RFC5204] and Responder validates the RELAY_HMAC according to [RFC5204] and
silently drops the packet if the validation fails. The Responder silently drops the packet if the validation fails. The Responder
replies with an R1 packet to which it includes a RELAY_TO parameter. replies with an R1 packet to which it includes a RELAY_TO parameter.
The RELAY_TO parameter MUST contain same information as the The RELAY_TO parameter MUST contain same information as the
RELAY_FROM parameter, i.e., the Initiator's transport address and the RELAY_FROM parameter, i.e., the Initiator's transport address, but
nonce, but the type of the parameter is different. The RELAY_TO the type of the parameter is different. The RELAY_TO parameter is
parameter is not integrity protected by the signature of the R1 to not integrity protected by the signature of the R1 to allow pre-
allow pre-created R1 packets at the Responder. created R1 packets at the Responder.
In step 4, the Relay receives the R1 packet. The Relay drops the In step 4, the relay receives the R1 packet. The relay drops the
packet silently if the source HIT belongs to an unregistered host. packet silently if the source HIT belongs to an unregistered host.
The Relay MAY verify the signature of the R1 packet and drop it if The relay MAY verify the signature of the R1 packet and drop it if
the signature is invalid. Otherwise, the Relay rewrites the source the signature is invalid. Otherwise, the relay rewrites the source
address and port, and changes the destination address and port to address and port, and changes the destination address and port to
match RELAY_TO information. Finally, the Relay recalculates match RELAY_TO information. Finally, the relay recalculates
transport checksum and forwards the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [RFC5201]. It replies with an I2 packet that uses the according to [RFC5201]. It replies with an I2 packet that uses the
destination transport address of R1 as the source address and port. destination transport address of R1 as the source address and port.
The I2 contains a LOCATOR parameter that lists all the ICE candidates The I2 contains a LOCATOR parameter that lists all the ICE candidates
(ICE offer) of the Initiator. The candidates are encoded using the (ICE offer) of the Initiator. The candidates are encoded using the
format defined in Section 4.5. The I2 packet MUST also contain the format defined in Section 5.7. The I2 packet MUST also contain the
NAT transform parameter with ICE-STUN-UDP or some other transform NAT traversal mode parameter with ICE-STUN-UDP or some other selected
selected because otherwise the Relay may drop the I2 packet. mode.
In step 6, the Relay receives the I2 packet. The relay appends a In step 6, the relay receives the I2 packet. The relay appends a
RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in the RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2.
second step.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC5201]. It replies with a R2 packet and includes a according to [RFC5201]. It replies with an R2 packet and includes a
RELAY_TO parameter as explained in step three. The R2 packet RELAY_TO parameter as explained in step 3. The R2 packet includes a
includes a LOCATOR parameter that lists all the ICE candidates (ICE LOCATOR parameter that lists all the ICE candidates (ICE answer) of
answer) of the Responder. The RELAY_TO parameter is protected by the the Responder. The RELAY_TO parameter is protected by the HMAC.
HMAC.
In step 8, the Relay processes the R2 as described in step four. The In step 8, the relay processes the R2 as described in step 4. The
Relay forwards the packet to the Responder. relay forwards the packet to the Initiator.
3.4. ICE Connectivity Checks Hosts MAY include the address of their HIP relay server in the
LOCATOR parameter in I2/R2. The traffic type of this address MUST be
"HIP signaling" and it MUST NOT be used as an ICE candidate. This
address MAY be used for HIP signaling also after the base exchange.
If the HIP relay server locator is not included in I2/R2 LOCATOR
parameters, it SHOULD NOT be used after the base exchange, but the
HIP signaling SHOULD use the same path as the data traffic.
The Responder completes the base exchange with the R2 packet through 4.6. ICE Connectivity Checks
the Relay. When Initiator successfully receives and processes the
R2, both hosts have transitioned to ESTABLISHED state. However, the
destination address the Initiator and Responder used for delivering
base exchange packets belonged to the Relay as indicated by the
RELAY_FROM and RELAY_TO parameters. Therefore, the address of the
Relay MUST not be used for sending ESP traffic unless it was listed
as a TURN server in the offer/answer. Instead, the Initiator and
Responder MUST start ICE connectivity tests after they have
transitioned to ESTABLISHED state after the base exchange when they
do not have valid locator pair for ESP traffic and the NAT transform
parameter was negotiated successfully.
The ICE connectivity checks are defined in [I-D.ietf-mmusic-ice]. If a HIP relay server was used, the Responder completes the base
Section Section 4.2 defines the details of the STUN control packets. exchange with the R2 packet through the relay. When the Initiator
As a result of the ICE connectivity checks, ICE nominates a single successfully receives and processes the R2, both hosts have
transport address pair to be used if an operational address could be transitioned to ESTABLISHED state. However, the destination address
the Initiator and Responder used for delivering base exchange packets
belonged to the HIP relay server. Therefore, the address of the
relay MUST NOT be used for sending ESP traffic. Instead, if a NAT
traversal mode with ICE connectivity checks was selected, the
Initiator and Responder MUST start the connectivity checks.
Creating the check list for the ICE connectivity checks should be
performed as described in Section 5.7 of [I-D.ietf-mmusic-ice]
bearing in mind that only one media stream and component is needed
(so there will be only a single checklist and all candidates should
have the same component ID value). The actual connectivity checks
MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice].
Regular mode SHOULD be used for the candidate nomination.
Section 5.2 defines the details of the STUN control packets. As a
result of the ICE connectivity checks, ICE nominates a single
transport address pair to be used if an operational address pair was
found. The end-hosts MUST use this address pair for the ESP traffic. found. The end-hosts MUST use this address pair for the ESP traffic.
3.5. NAT Keepalives The connectivity check messages MUST be paced by the value negotiated
during the base exchange as described in Section 4.4. If neither one
of the hosts announced a minimum pacing value, value of 500ms MUST be
used.
To prevent NAT state from expiring, communicating end-hosts hosts For retransmissions, the RTO value should be calculated as follows:
send periodically keepalives to each other. NAT Relays MUST not send
any keepalives. An end-host MUST send keepalives every 15 seconds to RTO = MAX (500ms, Ta * P)
refresh the UDP port mapping at the NAT(s) when the control or data
channel is idle. To implement failure tolerance, an end-host SHOULD In the RTO formula, Ta is the value used for the connectivity check
have shorter keepalive period. pacing and P is the number of pairs in the checklist when the
connectivity checks begin. This is identical to the formula in
[I-D.ietf-mmusic-ice] if there is only one checklist.
4.7. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send
periodically keepalives to each other. HIP relay servers MAY refrain
from sending keepalives if it's known that they are not behind a
middlebox that requires keepalives. An end-host MUST send keepalives
every 15 seconds to refresh the UDP port mapping at the NAT(s) when
the control or data channel is idle. To implement failure tolerance,
an end-host SHOULD have shorter keepalive period.
The keepalives are STUN Binding Indications if the hosts have agreed The keepalives are STUN Binding Indications if the hosts have agreed
on NAT_TRANSFORM during the base exchange, or HIP NOTIFY messages on ICE-STUN-UDP NAT traversal mode during the base exchange.
otherwise. A HIP Relay MUST not forward NOTIFY messages. Otherwise, HIP NOTIFY messages MAY be used. A HIP relay server MUST
NOT forward the NOTIFY messages.
The communicating hosts MUST send keepalives to each other using the The communicating hosts MUST send keepalives to each other using the
transport locators exchanged in the base exchange when they are in transport locators they agreed to use for data and signaling when
ESTABLISHED state. Also, the Initiator MUST send a NOTIFY message to they are in ESTABLISHED state. Also, the Initiator MUST send a
the Relay to refresh the NAT state alive on the path between the NOTIFY message to the relay to keep the NAT states alive on the path
Initiator and Relay when the Initiator has not received any response between the Initiator and relay when the Initiator has not received
to its I1 or I2 from the Responder in 15 seconds. The Relay MUST not any response to its I1 or I2 from the Responder in 15 seconds. The
forward the NOTIFY messages. relay MUST NOT forward the NOTIFY messages.
3.6. Base Exchange without ICE Connectivity Checks 4.8. Base Exchange without ICE Connectivity Checks
In certain network environments, the ICE connectivity checks can be In certain network environments, the ICE connectivity checks can be
omitted to reduce initial connection set up latency because base omitted to reduce initial connection set up latency because base
exchange acts an implicit connectivity test itself. There are three exchange acts as an implicit connectivity test itself. There are
assumptions about such as environments. First, the Responder should three assumptions about such as environments. First, the Responder
have a long-term, fixed locator in the network. Second, the should have a long-term, fixed locator in the network. Second, the
Responder should not have a HIP Relay configured for itself. Third, Responder should not have a HIP relay server configured for itself.
the Initiator can reach the Responder by simply UDP encapsulating HIP Third, the Initiator can reach the Responder by simply UDP
and ESP packets to the host. Detecting and configuring this encapsulating HIP and ESP packets to the host. Detecting and
particular scenario is prone to administrative failure unless configuring this particular scenario is prone to administrative
carefully planned. failure unless carefully planned.
In such a scenario, the Initiator sends an I1 packet over UDP to the In such a scenario, the Responder MAY include only the UDP-
Responder. The Responder replies with a R1 packet that does not ENCAPSULATION NAT traversal mode in the R1 message. Likewise, if the
contain the NAT transform parameter. The Initiator receives the R1 Initiator knows that it can receive ESP and HIP signaling traffic by
packet and determines from the absence of the NAT transform and using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION
RELAY_TO parameters that ICE connectivity checks can be omitted. mode in the I2 message, if the Responder listed it in the supported
Finally, the hosts can start to use the locators from the concluding modes. In both of these cases the locators from I2 and R2 packets
I2 and R2 packets of the base exchange for ESP without ICE will be used also for the UDP encapsulated ESP.
connectivity checks.
3.7. Base Exchange without UDP Encapsulation When no ICE connectivity checks are used, locator exchange and return
routability tests for mobility and multihoming are done as specified
in [RFC5206] with the exception that UDP encapsulation is used.
The Initiator MAY also try to establish a base exchange with the 4.9. Simultaneous Base Exchange with and without UDP Encapsulation
Responder without UDP encapsulation. In such a case, the Initiator
sends first an I1 packet without UDP encapsulation to the Responder.
After 100 ms, the Initiator MUST then send an UDP-encapsulated I1
packet. For retransmissions, the procedure is repeated.
The I1 packet may arrive directly at the Responder. When the The Initiator MAY also try to simultaneously perform a base exchange
recipient is the Responder, the proceduces in [RFC5201] are followed with the Responder without UDP encapsulation. In such a case, the
for the rest of the base exchange. The Initiator may receive Initiator sends two I1 packets, one without and one with UDP
multiple R1 messages from the Responder, but upon receiving a valid encapsulation, to the Responder. The Initiator MAY wait for a while
R1 without UDP encapsulation, the Initiator MUST ignore further R1 before sending the other I1. How long to wait and in which order to
messages with UDP encapsulation encapsulation. The end-hosts do not send the I1 packets can be decided based on local policy. For
trigger ICE connectivity checks after the base exchange since the UDP retransmissions, the procedure is repeated.
encapsulation was excluded.
The packet may also arrive at a HIP-capable middlebox. When the The I1 packet without UDP encapsulation may arrive directly at the
middlebox is a HIP rendezvous server and the Responder has Responder. When the recipient is the Responder, the procedures in
successfully registered to the rendezvous service, the middlebox [RFC5201] are followed for the rest of the base exchange. The
follows rendezvous procedures in [RFC5204]. If the middlebox is a Initiator may receive multiple R1 messages, with and without UDP
HIP Relay server, it drops the I1 packet silently. encapsulation, from the Responder. However, after receiving a valid
R1 and answering to it with an I2, further R1 messages that are not
retransmits of the original R1 MUST be ignored.
3.8. Sending Control Messages using the Data Plane The I1 packet without UDP encapsulation may also arrive at a HIP-
capable middlebox. When the middlebox is a HIP rendezvous server and
the Responder has successfully registered to the rendezvous service,
the middlebox follows rendezvous procedures in [RFC5204].
The end-hosts MAY send control messages directly to each other using If the Initiator receives a NAT traversal mode parameter in R1
the transport address pair established for data channel without without UDP encapsulation, the Initiator MAY ignore this parameter
sending the control packets through the Relay. When a host does not and send an I2 without UDP encapsulation and without any selected NAT
get acknowledgements e.g. to an UPDATE or CLOSE message after a traversal mode. When the Responder receives the I2 without UDP
timeout based on local policies, the host SHOULD resend the packet encapsulation and without NAT traversal mode, it will assume that no
through the Relay. This optimization requires further NAT traversal mechanism is needed. The packet processing will be
experimentation. done as described in [RFC5201]. The Initiator MAY store the NAT
traversal modes for future use e.g., to be used in case of mobility
or multihoming event which causes NAT traversal to be taken in to use
during the lifetime of the HIP association.
4. Packet Formats 4.10. Sending Control Messages after the Base Exchange
The following subsections define the parameter and packet encodings. After the base exchange, the end-hosts MAY send HIP control messages
All values MUST be in network byte order. directly to each other using the transport address pair established
for data channel without sending the control packets through the HIP
relay server. When a host does not get acknowledgments, e.g., to an
UPDATE or CLOSE message after a timeout based on local policies, the
host SHOULD resend the packet through the relay, if it was listed in
the LOCATOR parameter in the base exchange.
4.1. HIP Control Packets If control messages are sent through a HIP relay server, the sender
MUST include a RELAY_TO parameter to them. Also the HIP relay server
MUST add a RELAY_FROM parameter to the control messages it relays.
5. Packet Formats
The following subsections define the parameter and packet encodings
for the HIP, ESP and ICE connectivity check packets. All values MUST
be in network byte order.
5.1. HIP Control Packets
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes | | 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format for UDP-encapsulated HIP Control Packets Figure 5: Format of UDP-encapsulated HIP Control Packets
HIP control packets are encapsulated in UDP packets as defined in HIP control packets are encapsulated in UDP packets as defined in
Section 2.2 of [RFC3948], "rules for encapsulating IKE messages" Section 2.2 of [RFC3948], "rules for encapsulating IKE messages",
except for a different port number. Figure 4 illustrates the except a different port number is used. Figure 5 illustrates the
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC5201] with HIP header and parameters follow the conventions of [RFC5201] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
contains already a checksum. Second, the checksum definition in contains already a checksum. Second, the checksum definition in
[RFC5201] includes the IP addresses in the checksum calculation. The [RFC5201] includes the IP addresses in the checksum calculation. The
NATs unaware of HIP cannot recompute the HIP checksum after changing NATs unaware of HIP cannot recompute the HIP checksum after changing
IP addresses. IP addresses.
A HIP Relay or a Responder without a relay MUST listen at transport A HIP relay server or a Responder without a relay MUST listen at UDP
port HIPPORT for incoming UDP-encapsulated HIP control packets. port HIPPORT for incoming UDP encapsulated HIP control packets.
4.2. Connectivity Checks 5.2. Connectivity Checks
The connectivity checks are performed using STUN Binding Requests. The connectivity checks are performed using STUN Binding Requests as
This section describes the details of the parameters in the STUN defined in [I-D.ietf-mmusic-ice]. This section describes the details
messages. of the parameters in the STUN messages.
The username is formed from the username fragments as defined in The Binding Requests MUST use STUN short term credentials with HITs
section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The requests MUST use STUN of the Initiator and Responder as the username fragments. The
short term credentials with HITs of the Initiator and Responder username is formed from the username fragments as defined in Section
concatenated as a username fragment. The HITs are concatenated 7.1.1.3 of [I-D.ietf-mmusic-ice] with the Initiator being the
according to the Sort(HIT-I, HIT-R) algorithm defined in [RFC5201] "offerer" and the Responder being the "answerer". The HITs are used
section 6.5. The HIT username fragment MUST contain a UTF-8 as usernames by expressing them in IPv6 hexadecimal ASCII format
[RFC3629] encoded sequence and MUST have been processed using [RFC1884], using lowercase letters, each 16 bit HIT fragment
SASLPrep [RFC4013] as defined section 15.3 of separated by a one byte colon (hex 0x3a). The leading zeroes MUST
[I-D.ietf-behave-rfc3489bis]. The concatenated HIT pair MUST have a NOT be omitted so that the username's size is fixed.
fixed size that is accomplished by including the leading zeroes for
the HITs.
Drawing of HIP keys is defined in [RFC5201] section 6.5 and drawing The STUN password is drawn from the DH keying material. Drawing of
of ESP keys in [RFC5202] section 7. Correspondingly, the hosts MUST HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys
draw symmetric keys for STUN according to [RFC5201] section 6.5. The in [RFC5202] Section 7. Correspondingly, the hosts MUST draw
hosts draw the STUN keys after HIP keys, or after ESP keys if ESP symmetric keys for STUN according to [RFC5201] Section 6.5. The
transform was successfully negotiated in the base exchange. The hosts draw the STUN key after HIP keys, or after ESP keys if ESP
hosts draw two keys which they MUST use to generate the STUN transform was successfully negotiated in the base exchange. Both
password. As the STUN password is the same at both ends, the two hosts draw a 128 bit key from the DH keying material, express that in
drawn keys MUST be concatenated with the key for the greater HIT hexadecimal ASCII format using only lowercase letters (resulting in
first. Section 15.4 of [I-D.ietf-behave-rfc3489bis] describes how 32 numbers or lowercase letters), and use that as both the local and
hosts use the password for message integrity of STUN messages. peer password. [RFC5389] describes how hosts use the password for
message integrity of STUN messages.
Both the username and password are expressed in ASCII hexadecimal
format to prevent the need to run them through SASLPrep as defined in
[RFC5389].
The connectivity checks MUST contain PRIORITY attribute. They MAY The connectivity checks MUST contain PRIORITY attribute. They MAY
contain USE-CANDIDATE attributes as defined in section 7.1.1.1 of contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of
[I-D.ietf-mmusic-ice]. [I-D.ietf-mmusic-ice].
The Initiator is always in the controller role during a base The Initiator is always in the controller role during a base
exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes
are not needed and SHOULD NOT be used. When two hosts are initiating are not needed and SHOULD NOT be used. When two hosts are initiating
to each other simultaneously, HIP state machine detects it and a connection to each other simultaneously, HIP state machine detects
assigns the host with the larger HIT as the Responder as explained in it and assigns the host with the larger HIT as the Responder as
sections 4.4.2 and and 6.7 in [RFC5201]. explained in Sections 4.4.2 and 6.7 in [RFC5201].
4.3. Keepalives 5.3. Keepalives
The keepalives for HIP associations agreed that are NAT_TRANSFORM The keepalives for HIP associations that are created with ICE are
capable are STUN Binding Indications, as defined in STUN Binding Indications, as defined in [RFC5389]. In contrast to
[I-D.ietf-behave-rfc3489bis]. The source and destination ports are the UDP encapsulated HIP header, the non-ESP-marker between the UDP
in the UDP header are the same as used for HIP (50500). However, in header and the STUN header is excluded. Keepalives MUST contain the
contrast to the UDP encapsulated HIP header, there non-ESP-marker FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN
between the UDP header and the STUN header is excluded. Keepalives attributes and SHOULD NOT utilize any authentication mechanism. STUN
MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain messages are demultiplexed from ESP and HIP control messages using
any other STUN attributes and SHOULD NOT utilize any authentication the STUN markers, such as the magic cookie value and the FINGERPRINT
mechanism. STUN messages are demultiplexed from ESP and HIP control attribute.
messages using the STUN markers, such as the magic cookie value and
the FINGERPRINT attribute.
Keepalives for aHIP associations that are not NAT_TRANSFORM capable Keepalives for HIP associations created without ICE are HIP control
are HIP control messages that have NOTIFY as the packet type. The messages that have NOTIFY as the packet type. The NOTIFY messages do
NOTIFY messages do not contain any parameters. not contain any parameters.
4.4. Relay and Registration Parameters 5.4. NAT Traversal Mode Parameter
Format of the NAT_TRAVERSAL_MODE parameter is similar to the format
of the ESP_TRANSFORM parameter in [RFC5202] and is shown in the
Figure 6. This specification defines traversal mode identifiers UDP-
ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved
for future use. Future specifications may define more traversal
modes.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Reserved | Mode ID #1 |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type [ TBD by IANA: 608 ]
REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ] Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received
Mode ID defines the NAT traversal mode to be used
Length 20 The following NAT traversal mode IDs are defined:
Address An IPv6 address or an IPv4 address in "IPv4-compatible
IPv6 address" format ID Value
Port Transport port number; zero when plain IP is used RESERVED 0
Transport Transport protocol type; zero for UDP UDP-ENCAPSULATION 1
ICE-STUN-UDP 2
Figure 6: Format of the NAT_TRAVERSAL_MODE parameter
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that
there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. The limited number of Mode IDs sets the maximum size of
the NAT_TRAVERSAL_MODE parameter.
5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING parameter shown in Figure 7 contains only the
connectivity check pacing value, expressed in milliseconds, as 32 bit
unsigned integer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: 610 ]
Length length in octets, excluding Type and Length
Min Ta the minimum connectivity check transaction pacing
value the host would use
Figure 7: Format of the TRANSACTION_PACING parameter
5.6. Relay and Registration Parameters
Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown
in Figure 8. All parameters are identical except for the type.
REG_FROM is the only parameter covered with the signature.
Figure 5: Format for REG_FROM parameter
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type [ TBD by IANA:
Critical parameters: REG_FROM: 950
RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2) RELAY_FROM: 63998 (2^16 - 2^11 + 2^9 - 2)
RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2) RELAY_TO: 64002 (2^16 - 2^11 + 2^9 + 2) ]
Length 20
Length 24 Port transport port number; zero when plain IP is used
Address An IPv6 address or an IPv4 address in "IPv4-compatible Protocol IANA assigned, Internet Protocol number.
17 for UDP, 0 for plain IP.
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Port Transport port number; zero when plain IP is used
Transport Transport protocol type; zero for UDP
Nonce A nonce assigned by the Relay server.
Figure 6: Format for the RELAY_FROM and RELAY_TO parameters
Format for the REG_FROM parameter is shown in Figure 5, and Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters
RELAY_FROM and RELAY_TO in Figure 6. Parameters are identical except REG_FROM contains the transport address and protocol where the HIP
for the type and nonce fields. relay server sees the registration coming from. RELAY_FROM contains
the address where the relayed packet was received from by the relay
The nonce field is an experimental field for the RELAY_FROM and server and the protocol that was used. The RELAY_TO contains same
RELAY_TO parameters. It allows the Relay to have constant state information about the address where a packet should be forwarded to.
towards the Initiators without allowing the Responder to send R1 or
R2 packets to arbitrary hosts through the Relay.
4.5. LOCATOR Parameter 5.7. LOCATOR Parameter
The generic LOCATOR parameter format is the same as in [RFC5206]. The generic LOCATOR parameter format is the same as in [RFC5206].
However, presenting ICE candidates requires a new locator type. The However, presenting ICE candidates requires a new locator type. The
generic and NAT traversal specific locator parameters are illustrated generic and NAT traversal specific locator parameters are illustrated
in Figure 7. in Figure 9.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P| | Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 35 skipping to change at page 22, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind | | Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator | | Locator |
| | | |
| | | |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: LOCATOR parameter Figure 9: LOCATOR parameter
The individual fields in the LOCATOR parameter are described in The individual fields in the LOCATOR parameter are described in
Table 2. Table 2.
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose | | Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type | | Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and | | Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding | | | | Length fields and padding |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for | | Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) | | Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type | | Locator | 2 | "Transport address" locator type |
| Type | | | | Type | | |
| Locator | 7 | Length of the Locator field in 4-octet | | Locator | 7 | Length of the fields after Locator |
| Length | | units | | Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions | | Reserved | 0 | Reserved for future extensions |
| Preferred | 0 | Not used for transport address locators; | | Preferred | 0 | Not used for transport address locators; |
| (P) bit | | MUST be ignored by the receiver. | | (P) bit | | MUST be ignored by the receiver. |
| Locator | Variable | Locator lifetime in seconds | | Locator | Variable | Locator lifetime in seconds |
| Lifetime | | | | Lifetime | | |
| Transport | Variable | Transport layer port number | | Transport | Variable | Transport layer port number |
| Port | | | | Port | | |
| Transport | 0 | 0 for UDP | | Transport | Variable | IANA Assigned, transport layer Internet |
| Protocol | | | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-mmusic-ice] | | | | [I-D.ietf-mmusic-ice] |
| SPI | Variable | SPI value which the host expects to see in | | SPI | Variable | SPI value which the host expects to see in |
| | | incoming ESP packets that use this locator | | | | incoming ESP packets that use this locator |
| Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 | | Locator | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC3513], | | | | address" format IPv4 address [RFC3513] |
| | | obfuscated by XORing it with the owner's |
| | | HIT |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR parameter Table 2: Fields of the LOCATOR parameter
4.6. RELAY_HMAC 5.8. RELAY_HMAC Parameter
The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
2^4). It has the same semantics as RVS_HMAC [RFC5204]. 2^4). It has the same semantics as RVS_HMAC [RFC5204].
4.7. Registration Types 5.9. Registration Types
The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain
values for HIP Relay registration. The value for RELAY_UDP_HIP is 2. values for HIP relay server registration. The value for
The value for RELAY_UDP_ESP is 3. RELAY_UDP_HIP is 2.
4.8. ESP Data Packets 5.10. ESP Data Packets
[RFC3948] describes UDP encapsulation of the IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. On the wire, the HIP ESP packets do not differ from the tunnel mode. On the wire, the HIP ESP packets do not differ from the
transport mode ESP and thus the encapsulation of the HIP ESP packets transport mode ESP and thus the encapsulation of the HIP ESP packets
is same as the UDP encapsulation transport mode ESP. However, the is same as the UDP encapsulation transport mode ESP. However, the
(semantic) difference to BEET mode ESP packets used by HIP is that IP (semantic) difference to BEET mode ESP packets used by HIP is that IP
header is not used in BEET integrity protection calculation. header is not used in BEET integrity protection calculation.
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 (SAs) enable them to define a pair of IPsec ESP security associations (SAs)
as described in [RFC5202]. When two peers perform a UDP-encapsulated as described in [RFC5202]. When two peers perform a UDP-encapsulated
base exchange, they MUST define a pair of IPsec SAs that produces base exchange, they MUST define a pair of IPsec SAs that produces
UDP-encapsulated ESP data traffic. UDP-encapsulated ESP data traffic.
The management of encryption/authentication protocols and SPIs is The management of encryption/authentication protocols and SPIs is
defined in [RFC5202]. The UDP encapsulation format and processing of defined in [RFC5202]. The UDP encapsulation format and processing of
HIP ESP traffic is described in Section 6.1 of [RFC5202]. HIP ESP traffic is described in Section 6.1 of [RFC5202].
5. Security Considerations 6. Security Considerations
5.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in XORed format in plain text in favor of inspection The locators are in plain text format in favor of inspection at HIP-
at HIP-aware middleboxes in the future. The current draft does not aware middleboxes in the future. The current draft does not specify
specify encrypted versions of LOCATORs even though it could be encrypted versions of LOCATORs even though it could be beneficial for
beneficial for privacy reasons. privacy reasons.
It is possible that an Initiator or Responder may not want to reveal It is possible that an Initiator or Responder may not want to reveal
all of its locators to its peer. For example, a host may not want to all of its locators to its peer. For example, a host may not want to
reveal the internal topology of the private address realm and it reveal the internal topology of the private address realm and it
discards host addresses. Such behavior creates non-optimal paths discards host addresses. Such behavior creates non-optimal paths
when the hosts are located behind the same NAT. Especially, this when the hosts are located behind the same NAT. Especially, this
could be a problem with a legacy NAT that does not support routing could be a problem with a legacy NAT that does not support routing
from the private address realm back to itself through the outer from the private address realm back to itself through the outer
address of the NAT. This scenario is referred to as the hairpin address of the NAT. This scenario is referred to as the hairpin
problem [RFC5128]. With such a legacy NAT, the only option left problem [RFC5128]. With such a legacy NAT, the only option left
would be to use a relayed transport address from a TURN server. would be to use a relayed transport address from a TURN server.
As a consequence, a host may support locator-based privacy by leaving As a consequence, a host may support locator-based privacy by leaving
out the reflexive candidates. However, the trade-off in using only out the reflexive candidates. However, the trade-off in using only
host candidates can produce suboptimal paths that can congest the host candidates can produce suboptimal paths that can congest the
TURN server. The use of HIP Relays or TURN Relays can be useful for TURN server.
The use of HIP relay servers or TURN relays can be also useful for
protection against Denial-of-Service attacks. If a Responder reveals protection against Denial-of-Service attacks. If a Responder reveals
only its HIP Relay addresses and Relayed transport candidates to only its HIP relay server addresses and Relayed candidates to
Initiators, the Initiators can only attack the relays that does not Initiators, the Initiators can only attack the relays. That does not
prevent the Responder from initiating new outgoing connections if a prevent the Responder from initiating new outgoing connections if a
path around the relay exists. path around the relay exists.
5.2. Opportunistic Mode 6.2. Opportunistic Mode
A HIP Relay server should have one address per Relay Client when a A HIP relay server should have one address per relay client when a
HIP Relay is serving more than one Relay Clients and supports HIP relay is serving more than one relay clients and supports
opportunistic mode. Otherwise, it cannot be guaranteed that the opportunistic mode. Otherwise, it cannot be guaranteed that the HIP
Relay can deliver the I1 packet to the intended recipient. relay server can deliver the I1 packet to the intended recipient.
5.3. Base Exchange Replay Protection for HIP Relay Server 6.3. Base Exchange Replay Protection for HIP Relay Server
On certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a Relay server attackers, can replay an earlier base exchange through a HIP relay
by masquerading as the original Initiator and Responder. The attack server by masquerading as the original Initiator and Responder. The
does not require the attacker(s) to compromise the private key(s) of attack does not require the attacker(s) to compromise the private
the attacked host(s). However, Responder has to be disconnected from key(s) of the attacked host(s). However, for this attack to succeed,
the Relay in order to masquarade successfully as the Responder. the Responder has to be disconnected from the HIP relay server.
The Relay can protect itself against Replay attacks by involving in The relay can protect itself against replay attacks by involving in
the base exchange by introducing nonces that the end-hosts (Initiator the base exchange by introducing nonces that the end-hosts (Initiator
and Responder) have to sign. The Relay MAY add ECHO_REQUEST_M and Responder) have to sign. One way to do this is to add
parameters to the R1 and I2 messages as described in ECHO_REQUEST_M parameters to the R1 and I2 messages as described in
[I-D.heer-hip-middle-auth] and drops the I2 or R2 messages if the [I-D.heer-hip-middle-auth] and drop the I2 or R2 messages if the
corresponding ECHO_RESPONSE_M parameters are not present. corresponding ECHO_RESPONSE_M parameters are not present.
5.4. Demuxing Different HIP Associations 6.4. Demuxing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder use HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
6. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
This draft currently uses a UDP port in the "Dynamic and/or Private This draft currently uses a UDP port in the "Dynamic and/or Private
Port" and HIPPORT. Upon publication of this document, IANA is Port" and HIPPORT. Upon publication of this document, IANA is
requested to register a UDP port and the RFC editor is requested to requested to register a UDP port and the RFC editor is requested to
change all occurrences of port HIPPORT to the port IANA has change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial registered. The HIPPORT number 50500 should be used for initial
experimentation. experimentation.
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA Registry for HIP Parameter Types by
assigning new HIP Parameter Type values for the new HIP Parameters: assigning new HIP Parameter Type values for the new HIP Parameters:
RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 4.4) and RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.6),
RELAY_HMAC (defined in Section 4.6). NAT_TRANSFORM is also a new RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING (defined in
parameter. Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4).
7. Contributors 8. Contributors
This draft is a product of a design team which also included Marcelo This draft is a product of a design team which also included Marcelo
Bagnulo and Jan Melen who both have made major contributions to this Bagnulo and Jan Melen who both have made major contributions to this
document. document.
8. Acknowledgments 9. Acknowledgments
Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for 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 the excellent work on ICE. In addition, the authors would like to
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Vivien Schmitt, Abhinav Pathak for their contributions and Tobias Vivien Schmitt, Abhinav Pathak for their contributions and Tobias
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian
Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka
Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and
Varjonen, Dan Wing and Jani Hautakorpi for their comments on this Jani Hautakorpi for their comments on this document.
document.
Miika Komu is working in the Networking Research group at Helsinki Miika Komu is working in the Networking Research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project Institute for Information Technology (HIIT). The InfraHIP project
was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
Forces, and Ericsson and Birdstep. Forces, and Ericsson and Birdstep.
9. References 10. References
9.1. Normative References
[I-D.ietf-behave-rfc3489bis] 10.1. Normative References
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-16 (work in progress),
July 2008.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-08 (work in progress), June 2008. draft-ietf-behave-turn-11 (work in progress),
October 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.rosenberg-mmusic-ice-nonsip] [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Rosenberg, J., "NICE: Non Session Initiation Protocol Architecture", RFC 1884, December 1995.
(SIP) usage of Interactive Connectivity Establishment
(ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[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.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
skipping to change at page 24, line 7 skipping to change at page 27, line 42
Protocol (HIP) Registration Extension", RFC 5203, Protocol (HIP) Registration Extension", RFC 5203,
April 2008. April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
9.2. Informative References [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
10.2. Informative References
[I-D.heer-hip-middle-auth] [I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-01 (work in progress), draft-heer-hip-middle-auth-01 (work in progress),
July 2008. July 2008.
[I-D.irtf-hiprg-nat] [I-D.rosenberg-mmusic-ice-nonsip]
Stiemerling, M., "NAT and Firewall Traversal Issues of Rosenberg, J., "Guidelines for Usage of Interactive
Host Identity Protocol (HIP) Communication", Connectivity Establishment (ICE) by non Session
draft-irtf-hiprg-nat-04 (work in progress), March 2007. Initiation Protocol (SIP) Protocols",
draft-rosenberg-mmusic-ice-nonsip-01 (work in progress),
July 2008.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, March 2008. Translators (NATs)", RFC 5128, March 2008.
Appendix A. IPv4-IPv6 Interoperability [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008.
Currently Relay Client and Server do not have to run any ICE Appendix A. Selecting a Value for Check Pacing
connectivity tests as described in Section 3.6. However, it could be
useful for IPv4-IPv6 interoperability when the Relay Server actually Selecting a suitable value for the connectivity check transaction
includes both the NAT transform parameter and multiple locators in pacing is essential for the performance of connectivity check-based
R2. The interoperability benefit is that the Relay could support NAT traversal. The value should not be too small so that the checks
IPv4-based Initiators and IPv6-based Responders by converting the do not cause congestion in the network or overwhelm the NATs. On the
network headers and recalculating UDP checksums. other hand, too high pacing value makes the checks last for a long
time and thus increase the connection setup delay.
The Ta value may be configured by the user in environments where the
network characteristics are known beforehand. However, if the
characteristics are not know, it is recommended that the value is
adjusted dynamically. In this case it's recommended that the hosts
estimate the RTT between them and set the minimum Ta value so that
only two connectivity check messages are sent on every RTT.
One way to estimate the RTT is to use the time it takes for the HIP
relay server registration exchange to complete; this would give an
estimate on the registering host's access link's RTT. Also the I1/R1
exchange could be used for estimating the RTT, but since the R1 can
be cached in the network, or the relaying service can increase the
delay notably, it is not recommended.
Appendix B. IPv4-IPv6 Interoperability
Currently relay client and server do not have to run any ICE
connectivity tests as described in Section 4.8. However, it could be
useful for IPv4-IPv6 interoperability when the HIP relay server
actually includes both the NAT traversal mode parameter and multiple
locators in R2. The interoperability benefit is that the relay could
support IPv4-based Initiators and IPv6-based Responders by converting
the network headers and recalculating UDP checksums.
Such an approach is underspecified in this document currently. It is Such an approach is underspecified in this document currently. It is
not yet recommended because it may consume resources at the Relay and not yet recommended because it may consume resources at the relay and
requires also similar conversion support at the TURN relay for data requires also similar conversion support at the TURN relay for data
packets. packets.
Appendix B. Base Exchange through a Rendezvous Server Appendix C. Base Exchange through a Rendezvous Server
This section describes handling for a scenario where Initiator looks When the Initiator looks up the information of the Responder from
up the information of the Responder from DNS and discovers a RVS DNS, it's possible that it discovers an RVS record [RFC5204]. In
record [RFC5204]. In such a case, the Initiator uses its own HIP this case, if the Initiator uses NAT traversal methods described in
Relay to forward HIP traffic to the Rendezvous server. The Initiator this document, it uses its own HIP relay server to forward HIP
will send the I1 message using the its HIP Relay server which will traffic to the Rendezvous server. The Initiator will send the I1
then forward it to the RVS server of the responder. The responder message using its HIP relay server which will then forward it to the
will send the R1 packet directly to the Initiator's HIP Relay server RVS server of the Responder. In this case, the value of the protocol
and the following I2 and R2 packets are also sent directly using the field in the RELAY_TO parameter MUST be IP since RVS does not support
Relay. UDP encapsulated base exchange packets. The Responder will send the
R1 packet directly to the Initiator's HIP relay server and the
following I2 and R2 packets are also sent directly using the relay.
In case the Initiator is not able to distinguish which records are In case the Initiator is not able to distinguish which records are
RVS address records and which are Responders address records, then RVS address records and which are Responder's address records (e.g.,
the Initiator SHOULD first try to contact the Responder directly and if the DNS server did not support HIP extensions), the Initiator
if none of the addresses is reachable it MAY try out them using its SHOULD first try to contact the Responder directly, without using a
own HIP Relay as described in the above. HIP relay server. If none of the addresses is reachable, it MAY try
out them using its own HIP relay server as described above.
Appendix C. Document Revision History Appendix D. Document Revision History
To be removed upon publication To be removed upon publication
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| draft-ietf-nat-traversal-00 | Initial version. | | draft-ietf-nat-traversal-00 | Initial version. |
| draft-ietf-nat-traversal-01 | Draft based on RVS. | | draft-ietf-nat-traversal-01 | Draft based on RVS. |
| draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and |
| | ICE concepts. | | | ICE concepts. |
| draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. |
| draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | | draft-ietf-nat-traversal-04 | Issues 25-27,29-36 |
| draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
skipping to change at page 26, line 27 skipping to change at page 31, line 14
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Ari Keraenen (editor) Ari Keranen (editor)
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Phone: +358 9 2991 Phone: +358 9 2991
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Full Copyright Statement Full Copyright Statement
 End of changes. 175 change blocks. 
536 lines changed or deleted 733 lines changed or added

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