draft-ietf-hip-native-nat-traversal-11.txt   draft-ietf-hip-native-nat-traversal-12.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track M. Komu, Ed. Intended status: Standards Track M. Komu, Ed.
Expires: December 17, 2016 Ericsson Expires: December 25, 2016 Ericsson
June 15, 2016 June 23, 2016
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-11 draft-ietf-hip-native-nat-traversal-12
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2016. This Internet-Draft will expire on December 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7
4.2. Transport Address Candidate Gathering . . . . . . . . . . 9 4.2. Transport Address Candidate Gathering . . . . . . . . . . 9
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 11 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 11
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15
4.6.1. Aggressive Connectivity Checks . . . . . . . . . . . 15 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 15
4.6.2. Normal Connectivity Checks . . . . . . . . . . . . . 18 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 18
4.6.3. Rules for Connectivity Checks . . . . . . . . . . . . 20 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 19
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 22 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 19
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 22 4.7.2. Base Exchange without Connectivity Checks . . . . . . 20
4.7.2. Base Exchange without Connectivity Checks . . . . . . 22
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 23 Encapsulation . . . . . . . . . . . . . . . . . . . . 21
4.8. Sending Control Packets after the Base Exchange . . . . . 24 4.8. Sending Control Packets after the Base Exchange . . . . . 22
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 24 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 22
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 27 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 25
4.11. Close Procedure . . . . . . . . . . . . . . . . . . . . . 28 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 25
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 28 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 25
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 28 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 25
4.12.2. Relaying UDP Encapsulated Data and Control Packets . 29 4.12.2. Relaying UDP Encapsulated Control and Data Packets . 26
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 29 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 27
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 30 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 30 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 28
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 31 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 29
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 31 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 29
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 32 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 30
5.6. Relay and Registration Parameters . . . . . . . . . . . . 33 5.6. Relay and Registration Parameters . . . . . . . . . . . . 30
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 34 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 31
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 35 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 33
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 36 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 33
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 36 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 34
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 36 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 34
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 37 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 35
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 38 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 35
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 39 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 36
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 39 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 40 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 37
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 40 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 38
6.3. Base Exchange Replay Protection for HIP Relay Server . . 40 6.3. Base Exchange Replay Protection for HIP Relay Server . . 38
6.4. Demuxing Different HIP Associations . . . . . . . . . . . 41 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 38
6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 41 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 39
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . 42 10.1. Normative References . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 44 10.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 44 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 42
Appendix B. Base Exchange through a Rendezvous Server . . . . . 45 Appendix B. Base Exchange through a Rendezvous Server . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in directly on top of IPv4 or IPv6. However, many middleboxes found in
the Internet, such as NATs and firewalls, often allow only UDP or TCP the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, especially NATs usually require the traffic to pass [RFC5207]. Also, especially NATs usually require the
host behind a NAT to create a forwarding state in the NAT before host behind a NAT to create a forwarding state in the NAT before
other hosts outside of the NAT can contact the host behind the NAT. other hosts outside of the NAT can contact the host behind the NAT.
To overcome this problem, different methods, commonly referred to as To overcome this problem, different methods, commonly referred to as
NAT traversal techniques, have been developed. NAT traversal techniques, have been developed.
Two NAT traversal techniques for HIP are specified in [RFC5770]. One Two NAT traversal techniques for HIP are specified in [RFC5770]. One
of them uses only UDP encapsulation, while the other uses also the of them uses only UDP encapsulation, while the other uses also the
Interactive Connectivity Establishment (ICE) [RFC5245] protocol, Interactive Connectivity Establishment (ICE)
which in turn uses Session Traversal Utilities for NAT (STUN) [I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session
[RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using
protocols to achieve a reliable NAT traversal solution. Relays around NAT (TURN) [RFC5766] protocols to achieve a reliable
NAT traversal solution.
The benefit of using ICE and STUN/TURN is that one can re-use the NAT The benefit of using ICE and STUN/TURN is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
STUN and TURN servers. Also, some middleboxes may be STUN-aware and STUN and TURN servers. Also, some middleboxes may be STUN-aware and
could be able to do something "smart" when they see STUN being used could be able to do something "smart" when they see STUN being used
for NAT traversal. However, implementing a full ICE/STUN/TURN for NAT traversal. However, implementing a full ICE/STUN/TURN
protocol stack results in a considerable amount of effort and code protocol stack results in a considerable amount of effort and code
which could be avoided by re-using and extending HIP messages and which could be avoided by re-using and extending HIP messages and
state machines for the same purpose. Thus, this document specifies state machines for the same purpose. Thus, this document specifies
an alternative NAT traversal mode that uses HIP messages instead of an alternative NAT traversal mode that uses HIP messages instead of
STUN for the connectivity checks, keepalives, and data relaying. STUN for the connectivity checks keepalives, and data relaying. This
This document also specifies how mobility management works in the document also specifies how mobility management works in the context
context of NAT traversal, which was missing from [RFC5770]. of NAT traversal, which was missing from [RFC5770].
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 [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[I-D.ietf-hip-rfc5206-bis], [RFC4423], [RFC5245], and [RFC5389]. The [I-D.ietf-hip-rfc5206-bis], [RFC4423], [I-D.ietf-ice-rfc5245bis], and
following terms recur in the text: [RFC5389]. The following terms recur in the text:
HIP relay server: HIP relay server:
A host that forwards any kind of HIP control packets between the A host that forwards any kind of HIP control packets between the
Initiator and the Responder. Initiator and the Responder.
HIP data relay: HIP data relay:
A host that forwards HIP data packets, such as Encapsulating A host that forwards HIP data packets, such as Encapsulating
Security Payload (ESP) [RFC7402], between two hosts. Security Payload (ESP) [RFC7402], between two hosts.
Registered host: Registered host:
skipping to change at page 6, line 46 skipping to change at page 6, line 46
The first steps are for both the Initiator and Responder to register 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 with a relay server (need not be the same one) and gather a set of
address candidates. The hosts may use HIP relay servers (or even address candidates. The hosts may use HIP relay servers (or even
STUN or TURN servers) for gathering the candidates. Next, the HIP STUN or TURN servers) for gathering the candidates. Next, the HIP
base exchange is carried out by encapsulating the HIP control packets base exchange is carried out by encapsulating the HIP control packets
in UDP datagrams and sending them through the Responder's relay in UDP datagrams and sending them through the Responder's relay
server. As part of the base exchange, each HIP host learns of the server. As part of the base exchange, each HIP host learns of the
peer's candidate addresses through the HIP offer/answer procedure peer's candidate addresses through the HIP offer/answer procedure
embedded in the base exchange, which follows closely the ICE embedded in the base exchange, which follows closely the ICE
[RFC5245] protocol. [I-D.ietf-ice-rfc5245bis] protocol.
Once the base exchange is completed, two HIP hosts have established a Once the base exchange is completed, two HIP hosts have established a
working communication session (for signaling) via a HIP relay server, working communication session (for signaling) via a HIP relay server,
but the hosts still have to find a better path, preferably without a but the hosts still have to find a better path, preferably without a
HIP data relay, for the ESP data flow. For this, connectivity checks HIP data relay, for the ESP data flow. For this, connectivity checks
are carried out until a working pair of addresses is discovered. At are carried out until a working pair of addresses is discovered. At
the end of the procedure, if successful, the hosts will have the end of the procedure, if successful, the hosts will have
established a UDP-based tunnel that traverses both NATs, with the established a UDP-based tunnel that traverses both NATs, with the
data flowing directly from NAT to NAT or via a HIP data relay server. data flowing directly from NAT to NAT or via a HIP data relay server.
At this point, also the HIP signaling can be sent over the same At this point, also the HIP signaling can be sent over the same
skipping to change at page 8, line 4 skipping to change at page 8, line 4
devices, a host MAY also register for UDP encapsulated ESP relaying devices, a host MAY also register for UDP encapsulated ESP relaying
using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This
service may be coupled with the HIP relay server or offered service may be coupled with the HIP relay server or offered
separately on another server. If the server supports relaying of UDP separately on another server. If the server supports relaying of UDP
encapsulated ESP, the host is allowed to register for a data relaying encapsulated ESP, the host is allowed to register for a data relaying
service using the registration extensions in Section 3.3 of service using the registration extensions in Section 3.3 of
[I-D.ietf-hip-rfc5203-bis]). If the server has sufficient relaying [I-D.ietf-hip-rfc5203-bis]). If the server has sufficient relaying
resources (free port numbers, bandwidth, etc.) available, it opens a resources (free port numbers, bandwidth, etc.) available, it opens a
UDP port on one of its addresses and signals the address and port to UDP port on one of its addresses and signals the address and port to
the registering host using the RELAYED_ADDRESS parameter (as defined the registering host using the RELAYED_ADDRESS parameter (as defined
in section Section 5.12 in this document). If the relay would accept in Section 5.12 in this document). If the relay would accept the
the data relaying request but does not currently have enough data relaying request but does not currently have enough resources to
resources to provide data relaying service, it MUST reject the provide data relaying service, it MUST reject the request with
request with Failure Type "Insufficient resources" Failure Type "Insufficient resources" [I-D.ietf-hip-rfc5203-bis].
[I-D.ietf-hip-rfc5203-bis].
A HIP relay server MUST silently drop packets to a HIP relay client A HIP relay server MUST silently drop packets to a HIP relay client
that has not previously registered with the HIP relay. The that has not previously registered with the HIP relay. The
registration process follows the generic registration extensions registration process follows the generic registration extensions
defined in [I-D.ietf-hip-rfc5203-bis]. The HIP control plane defined in [I-D.ietf-hip-rfc5203-bis]. The HIP control plane
relaying registration follows [RFC5770], but the data plane relaying registration follows [RFC5770], but the data plane
registration is different. It is worth noting that if the HIP registration is different. It is worth noting that if the HIP
control and data plane relay services reside on different hosts, the control and data plane relay services reside on different hosts, the
relay client has to register separately to each of them. In the relay client has to register separately to each of them. In the
example shown in in Figure 2, the two services are coupled on a example shown in Figure 2, the two services are coupled on a single
single host. host.
HIP HIP HIP HIP
Relay [Data] Relay Relay [Data] Relay
Client Server Client Server
| 1. UDP(I1) | | 1. UDP(I1) |
+---------------------------------------------------------------->| +---------------------------------------------------------------->|
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
skipping to change at page 9, line 29 skipping to change at page 9, line 29
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 (if any) parameter. The Responder denotes unsuccessful registrations (if any)
in the REG_FAILED parameter of R2. The Responder also includes a in the REG_FAILED parameter of R2. The Responder also includes a
REG_FROM parameter that contains the transport address of the client REG_FROM parameter that contains the transport address of the client
as observed by the relay (Server Reflexive candidate). If the as observed by the relay (Server Reflexive candidate). If the
Initiator registered to ESP relaying service, the Responder includes Initiator registered to ESP relaying service, the Responder includes
RELAYED_ADDRESS paramater that describes the UDP port allocated to RELAYED_ADDRESS paramater that describes the UDP port allocated to
the Initiator for ESP relaying. It is worth noting that this client the Initiator for ESP relaying. It is worth noting that this client
must first activate this UDP port by sending an UPDATE message to the must first activate this UDP port by sending an UPDATE message to the
relay server that includes a PEER_PERMISSION parameter as described relay server that includes a PEER_PERMISSION parameter as described
in section Section 4.12.1. in Section 4.12.1 both after base exchange and handover procedures.
After the registration, the relay client sends periodically NAT After the registration, the relay client sends periodically NAT
keepalives to the relay server in order to keep the NAT bindings keepalives to the relay server in order to keep the NAT bindings
between the initiator and the relay alive. The keepalive extensions between the initiator and the relay alive. The keepalive extensions
are described in Section 4.10. are described in Section 4.10.
The registered host MUST maintain an active HIP association with the The registered host MUST maintain an active HIP association with the
data relay as long as it requires the data relaying service. When data relay as long as it requires the data relaying service. When
the HIP association is closed (or times out), or the registration the HIP association is closed (or times out), or the registration
lifetime passes without the registered host refreshing the lifetime passes without the registered host refreshing the
skipping to change at page 12, line 12 skipping to change at page 12, line 12
packets. The parameter contains the minimum time (expressed in packets. The parameter contains the minimum time (expressed in
milliseconds) the host would wait between two NAT traversal milliseconds) the host would wait between two NAT traversal
transactions, such as starting a new connectivity check or retrying a transactions, such as starting a new connectivity check or retrying a
previous check. The value that is used by both of the hosts is the previous check. The value that is used by both of the hosts is the
higher out of the two offered values. higher out of the two offered values.
The minimum Ta value SHOULD be configurable, and if no value is The minimum Ta value SHOULD be configurable, and if no value is
configured, a value of 500 ms MUST be used. Guidelines for selecting configured, a value of 500 ms MUST be used. Guidelines for selecting
a Ta value are given in Appendix A. Hosts SHOULD NOT use values a Ta value are given in Appendix A. Hosts SHOULD NOT use values
smaller than 20 ms for the minimum Ta, since such values may not work smaller than 20 ms for the minimum Ta, since such values may not work
well with some NATs, as explained in [RFC5245]. The Initiator MUST well with some NATs, as explained in [I-D.ietf-ice-rfc5245bis]. The
NOT propose a smaller value than what the Responder offered. If a Initiator MUST NOT propose a smaller value than what the Responder
host does not include the TRANSACTION_PACING parameter in the base offered. If a host does not include the TRANSACTION_PACING parameter
exchange, a Ta value of 500 ms MUST be used as that host's minimum in the base exchange, a Ta value of 500 ms MUST be used as that
value. host's minimum value.
4.5. Base Exchange via HIP Relay Server 4.5. Base Exchange via HIP Relay Server
This section describes how the Initiator and Responder perform a base This section describes how the Initiator and Responder perform a base
exchange through a HIP relay server. Connectivity pacing (denoted as exchange through a HIP relay server. Connectivity pacing (denoted as
TA_P here) was described in Section 4.4 and is neither repeated here. TA_P here) was described in Section 4.4 and is neither repeated here.
Similarly, the NAT traversal mode negotiation process (denoted as Similarly, the NAT traversal mode negotiation process (denoted as
NAT_TM in the example) was described in Section 4.3 and is neither NAT_TM in the example) was described in Section 4.3 and is neither
repeated here. If a relay receives an R1 or I2 packet without the repeated here. If a relay receives an R1 or I2 packet without the
NAT traversal mode parameter, it MUST drop it and SHOULD send a NAT traversal mode parameter, it MUST drop it and SHOULD send a
NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER
to the sender of the R1 or I2. to the sender of the R1 or I2.
It is RECOMMENDED that the Initiator send an I1 packet encapsulated It is RECOMMENDED that the Initiator send 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 a Respectively, the Responder MUST respond to such an I1 packet with a
UDP-encapsulated R1 packet, and also the rest of the communication UDP-encapsulated R1 packet, and also the rest of the communication
related to the HIP association MUST also use UDP encapsulation. related to the HIP association MUST also use UDP encapsulation.
Figure Figure 4 illustrates a base exchange via a HIP relay server. Figure 4 illustrates a base exchange via a HIP relay server. We
We assume that the Responder (i.e. a HIP relay client) has already assume that the Responder (i.e. a HIP relay client) has already
registered to the HIP relay server. The Initiator may have also registered to the HIP relay server. The Initiator may have also
registered to another (or the same relay server), but the base registered to another (or the same relay server), but the base
exchange will traverse always through the relay of the Responder. exchange will traverse always through the relay of the Responder.
Initiator HIP relay Responder Initiator HIP relay Responder
| 1. UDP(I1) | | | 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) | +--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TM, | | | 3. UDP(R1(RELAY_TO, NAT_TM, |
skipping to change at page 15, line 25 skipping to change at page 15, line 25
the HIP relay, both of them employ the IP address of the relay as the the HIP relay, both of them employ the IP address of the relay as the
destination address for the packets. This address MUST NOT be used destination address for the packets. This address MUST NOT be used
as a destination for ESP traffic unless the HIP relay supports also as a destination for ESP traffic unless the HIP relay supports also
ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was
successfully negotiated and selected, the Initiator and Responder successfully negotiated and selected, the Initiator and Responder
MUST start the connectivity checks in order to attempt to obtain MUST start the connectivity checks in order to attempt to obtain
direct end-to-end connectivity through NAT devices. direct end-to-end connectivity through NAT devices.
The connectivity checks follow the ICE methodology [MMUSIC-ICE], but The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
UDP encapsulated HIP control messages are used instead of ICE UDP encapsulated HIP control messages are used instead of ICE
messages. Similarly as in ICE, both regular and aggressive mode for messages. Only normal connectivity checks can be used because
nominating address candidates can be used. The Initiator MUST take aggressive connectivity checks are deprecated. The Initiator MUST
the role of controlling host and the Responder acts as the controlled take the role of controlling host and the Responder acts as the
host. The protocol follows standard HIP UPDATE sending and controlled host. The protocol follows standard HIP UPDATE sending
processing rules as defined in section 6.11 and 6.12 in [RFC7401], and processing rules as defined in section 6.11 and 6.12 in
but some new parameters are introduced: CANDIDATE_PRIORITY, [RFC7401], but some new parameters are introduced:
MAPPED_ADDR and NOMINATE. CANDIDATE_PRIORITY, MAPPED_ADDR and NOMINATE.
4.6.1. Aggressive Connectivity Checks 4.6.1. Connectivity Check Procedure
Figure Figure 5 illustrates connectivity checks in a simplified Figure 5 illustrates connectivity checks in a simplified scenario,
scenario, where the Initiator and Responder have only a single where the Initiator and Responder have only a single candidate pair
candidate pair to check and they employ aggressive mode. Typically, to check. Typically, NATs drop messages messages until both sides
NATs drop messages messages until both sides have sent messages using have sent messages using the same port pair. In this scenario, the
the same port pair. In this scenario, the Responder sends a Responder sends a connectivity check first but the NAT of the
connectivity check first but the NAT of the Initiator drops it. Initiator drops it. However, the connectivity check from the
However, the connectivity check from the Initiator reaches the Initiator reaches the Responder because it uses the same port pair as
Responder because it uses the same port pair as the first message. the first message.
Initiator NAT1 NAT2 Responder Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | | | | ECHO_REQ_SIGN)) | |
| X<-+------------------------------------+----------------+ | X<-----------------------------------+----------------+
| | | | | | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->| +-------------+------------------------------------+--------------->|
| | | | | | | |
| 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| MAPPED_ADDR, NOMINATE)) | | | | MAPPED_ADDR)) | |
|<------------+------------------------------------+----------------+ |<------------+------------------------------------+----------------+
| | | | | | | |
| 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | | 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
+-------------+------------------------------------+--------------->+ +-------------+------------------------------------+--------------->+
| | | | | | | |
| 5. ESP data traffic over UDP | | | 5. Other connectivity checks using UPDATE over UDP |
<-------------+------------------------------------+---------------->
| | | |
| 6. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
+-------------+------------------------------------+--------------->|
| | | |
| 7. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | |
|<------------+------------------------------------+----------------+
| | | |
| 8. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
+-------------+------------------------------------+--------------->+
| | | |
| 9. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+ +<------------+------------------------------------+--------------->+
| | | | | | | |
Figure 5: Aggressive Connectivity Checks, Scenario A Figure 5: Connectivity Checks
In step 1, the Responder sends a connectivity check to the Initiator In step 1, the Responder sends a connectivity check to the Initiator
that the NAT of the Initiator drops. The message includes a number that the NAT of the Initiator drops. The message includes a number
of parameters. As specified in [RFC7401]), the SEQ parameter of parameters. As specified in [RFC7401]), the SEQ parameter
includes a running sequence identifier for the connectivity check. includes a running sequence identifier for the connectivity check.
The candidate priority (denoted "CAND_PRIO" in the figure) describes The candidate priority (denoted "CAND_PRIO" in the figure) describes
the priority of the address candidate being tested. The the priority of the address candidate being tested. The
ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a
nonce that the recipient must sign and echo back as it is. nonce that the recipient must sign and echo back as it is.
In step 2,the Responder sends a connectivity check using the same In step 2, the Initiator sends a connectivity check using the same
address pair candidate as the Initiator did and the message traverses address pair candidate as the Responder did and the message traverses
successfully the NAT boxes. The message includes the same parameters successfully the NAT boxes. The message includes the same parameters
as in the previous step. However, since Initiator is employing as in the previous step.
aggressive mode, it also includes NOMINATE parameter in the message.
This signals that the connectivity checks should be conclude upon
finding the first working address pair candidates.
In step 3, the Responder has successfully received the previous In step 3, the Responder has successfully received the previous
connectivity check from the Initiator and starts to build a response connectivity check from the Initiator and starts to build a response
message. Since the message from the Initiator included a SEQ, the message. Since the message from the Initiator included a SEQ, the
Responder must acknowledge it using an ACK parameter. Also, the Responder must acknowledge it using an ACK parameter. Also, the
nonce contained in the echo request must be echoed back in an nonce contained in the echo request must be echoed back in an
ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. In ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The
addition to these two parameters, the Responder includes an NOMINATE Responder includes also a MAPPED_ADDRESS parameter that contains the
parameter to confirm that the current address pair candidate is transport address of the Initiator as observed by the Responder (i.e.
selected for use. The Responder includes also a MAPPED_ADDRESS peer reflexive candidate). The Initiator should acknowledge the
parameter that contains the transport address of the Initiator as message from the Responder, so the Responder also includes its own
observed by the Responder (i.e. peer reflexive candidate). The SEQ in the message and its own echo request for additional security.
Initiator should acknowledge the message from the Responder, so it
also includes its own SEQ in the message and its own echo request for
additional security.
In step 4, the Initiator receives the message from the Responder and In step 4, the Initiator receives the message from the Responder and
builds a corresponding response that concludes connectivity checks. builds a corresponding response that concludes connectivity checks.
Since the previous message from the Responder included a new SEQ and Since the previous message from the Responder included a new SEQ and
ECHO_REQUEST_SIGN parameters, the Initiator includes the ECHO_REQUEST_SIGN parameters, the Initiator includes the
corresponding ACK and ECHO_RESPONSE_SIGN parameters. Before sending, corresponding ACK and ECHO_RESPONSE_SIGN parameters. Before sending,
it also includes a MAPPED_ADDR parameter describing the peer it also includes a MAPPED_ADDR parameter describing the peer
reflexive candidate. reflexive candidate.
In step 5, the Responder has received the message from the Initiator
and both end-points create the corresponding IPsec security
associations that can be used for delivering application payload.
Figure Figure 6 illustrates aggressive connectivity checks. For
simplicity, the hosts test here only a single address candidate. The
difference to the previous scenario is that Initiator sends the first
connectivity test that is then dropped by the NAT of the Responder.
Initiator NAT1 NAT2 Responder
| | | |
| 1. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
+------------>+----------------------------------->+->X |
| | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
|<------------+------------------------------------+----------------+
| | | |
| 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN |
| MAPPED_ADDR, NOMINATE)) | |
+-------------+------------------------------------+--------------->+
| | | |
| 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR, NOMINATE)) |
+<------------+------------------------------------+----------------+
| | | |
| 5. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+
| | | |
| | | |
Figure 6: Aggressive Connectivity Checks, Scenario B
In step 1, the Initiator sends the first connectivity check message
to the Responder, but the packet is dropped by the NAT of the
Responder.
In step 2, the Responder sends a connectivity check message to the
Initiator that passes both NATs. The message includes SEQ,
ECHO_REQUEST_SIGN and CANDIDATE_PRIORITY parameters.
In step 3, the Initiator receives the message from the Responder. It
constructs a response message that includes an ACK and
ECHO_RESPONSE_SIGN parameters that acknowledge the corresponding SEQ
and ECHO_REQUEST_SIGN parameters from the previous message from the
Responder. The response message also includes a new SEQ and
ECHO_REQUEST_SIGN parameters to be acknowledged by the Responder.
The responder also includes the peer reflexive candidate in
MAPPED_ADDR parameter and NOMINATE (since it employs aggressive
connectivity checks).
In step 4, the Responder receives the message from the Initiator and
builds a response message, where the ACK and ECHO_RESP_SIGN
parameters correspond to the SEQ and ECHO_REQUEST_SIGN parameters in
the previously received message. The Responder includes also the
peer reflexive candidate in MAPPED_ADDR parameter and confirms the
completion of the candidate nomination with the NOMINATE parameter.
In step 5, the candidate nomination is complete and the hosts can
start to exchange application payload.
4.6.2. Normal Connectivity Checks
Normal connectivity checks are similar as aggressive, but the
difference is that the controlling host (i.e. Initiator) does not
include the NOMINATE parameter until all candidates have been tested.
Figure Figure 6 illustrates normal connectivity checks (in the same
scenario as illustrated in figure Figure 5).
Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | |
| X<-+------------------------------------+----------------+
| | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->|
| | | |
| 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| | MAPPED_ADDR)) | |
|<------------+------------------------------------+----------------+
| | | |
| 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
+-------------+------------------------------------+--------------->+
| | | |
| 5. Other connectivity checks using UPDATE over UDP |
<-------------+------------------------------------+---------------->
| | | |
| 6. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
+-------------+------------------------------------+--------------->|
| | | |
| 7. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | |
|<------------+------------------------------------+----------------+
| | | |
| 8. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
+-------------+------------------------------------+--------------->+
| | | |
| 9. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+
| | | |
Figure 7: Normal Connectivity Checks
Steps 1-4 are identical to the same steps in figure Figure 5. The
difference here is that the initiator does not include the NOMINATE
parameter.
In step 5, the Initiator and Responder test the remaining address In step 5, the Initiator and Responder test the remaining address
candidates (if any) because the Initiator did not elect an address candidates (if any).
candidate with the NOMINATE parameter.
In step 6, the Initiator has completed testing all address candidates In step 6, the Initiator has completed testing all address candidates
and nominates one address candidate to be used. It sends an UPDATE and nominates one address candidate to be used. It sends an UPDATE
message using the selected address candidates that includes a number message using the selected address candidates that includes a number
of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the
NOMINATE parameter. NOMINATE parameter.
In step 7, the Responder receives the message with NOMINATE parameter In step 7, the Responder receives the message with NOMINATE parameter
from the Initiator. It sends a response that includes the NOMINATE from the Initiator. It sends a response that includes the NOMINATE
parameter in addition to a number of other parameters. The ACK and parameter in addition to a number of other parameters. The ACK and
skipping to change at page 20, line 22 skipping to change at page 17, line 51
In step 8, the Initiator completes the candidate nomination process In step 8, the Initiator completes the candidate nomination process
by confirming the message reception to the Responder. In the by confirming the message reception to the Responder. In the
confirmation message, the ACK and ECHO_RESPONSE_SIGN parameters confirmation message, the ACK and ECHO_RESPONSE_SIGN parameters
correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message
sent by the Responder in the previous step. sent by the Responder in the previous step.
In step 9, the Initiator and Responder can start sending application In step 9, the Initiator and Responder can start sending application
payload over the successfully nominated address candidates. payload over the successfully nominated address candidates.
Compared to aggressive connectivity steps, it is worth noting that It is worth noting that if either host has registered a relayed
the MAPPED_ADDRESS does not need to be included in normal address candidate from a data relay, the host MUST activate the
connectivity checks in the messages sent in steps 7 and 8. address before connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1.
Otherwise, the relay drops ESP packets using the relayed address.
4.6.3. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
All of the connectivity check packets MUST be protected with HMACs All of the connectivity check packets MUST be protected with HMACs
and signatures (even though the illustrations omitted them for and signatures (even though the illustrations omitted them for
simplicity). To provide strong replay protection, for each pair of simplicity). To provide strong replay protection, for each pair of
address candidates, both the Initiator and Responder MUST send a send address candidates, both the Initiator and Responder MUST send a send
a nonce to each other for signing using the ECHO_REQUEST_SIGNED a nonce to each other for signing using the ECHO_REQUEST_SIGNED
parameter (that then has to be echoed back by the recipient). parameter (that then has to be echoed back by the recipient).
Similarly, the SEQ parameter enforces the the recipient to Similarly, the SEQ parameter enforces the the recipient to
acknowledge a received message. Effectively these two mechanisms acknowledge a received message. Effectively these two mechanisms
combined result in a secure three way packet exchange that tests both combined result in a secure three way packet exchange that tests both
skipping to change at page 21, line 26 skipping to change at page 19, line 11
this results in a bit more unnecessary packet exchanges, but both this results in a bit more unnecessary packet exchanges, but both
ends SHOULD nevertheless complete the three way connectivity check ends SHOULD nevertheless complete the three way connectivity check
process they initiated. process they initiated.
The connectivity check messages MUST be paced by the value negotiated The connectivity check messages MUST be paced by the value negotiated
during the base exchange as described in Section 4.4. If neither one during the base exchange as described in Section 4.4. If neither one
of the hosts announced a minimum pacing value, a value of 500 ms MUST of the hosts announced a minimum pacing value, a value of 500 ms MUST
be used. be used.
As defined in [RFC5770], both hosts MUST form a priority ordered As defined in [RFC5770], both hosts MUST form a priority ordered
checklist and start check transactions every Ta milliseconds as long checklist and start to check transactions every Ta milliseconds as
as the checks are running and there are candidate pairs whose tests long as the checks are running and there are candidate pairs whose
have not started. The retransmission timeout (RTO) for the tests have not started. The retransmission timeout (RTO) for the
connectivity check UPDATE packets MUST be calculated as follows: connectivity check UPDATE packets MUST be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
"In-Progress" state. This is identical to the formula in [RFC5245] "In-Progress" state. This is identical to the formula in
if there is only one checklist. [I-D.ietf-ice-rfc5245bis] if there is only one checklist.
Each connectivity check request packet MUST contain a Each connectivity check request packet MUST contain a
CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority
value that would be assigned to a peer reflexive candidate if one was value that would be assigned to a peer reflexive candidate if one was
learned from the corresponding check. An UPDATE packet that learned from the corresponding check. An UPDATE packet that
acknowledges a connectivity check request MUST be sent from the same acknowledges a connectivity check request MUST be sent from the same
address that received the check and delivered to the same address address that received the check and delivered to the same address
where the check was received from. Each acknowledgment UPDATE packet where the check was received from. Each acknowledgment UPDATE packet
MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and
IP address of the address where the connectivity check request was IP address of the address where the connectivity check request was
skipping to change at page 25, line 10 skipping to change at page 22, line 44
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [I-D.ietf-hip-rfc5206-bis] define Mobility extensions for HIP [I-D.ietf-hip-rfc5206-bis] define
handover procedures without NATs. In this section, we define how two handover procedures without NATs. In this section, we define how two
hosts interact handover procedures in scenarios involving NATs. The hosts interact handover procedures in scenarios involving NATs. The
specified extensions define only simple mobility using a pair of specified extensions define only simple mobility using a pair of
security associations, and multihoming extensions are left to be security associations, and multihoming extensions are left to be
defined in later specifications. defined in later specifications.
We assume that the two hosts have successfully negotiated and chosen We assume that the two hosts have successfully negotiated and chosen
the ICE-HIP-UDP mode during the base exchange as defined in section the ICE-HIP-UDP mode during the base exchange as defined in
Section 4.3. The Initiator of the base exchange MUST store Section 4.3. The Initiator of the base exchange MUST store
information that it was the controlling host during the base information that it was the controlling host during the base
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
The mobility extensions for NAT traversal are illustrated in figure The mobility extensions for NAT traversal are illustrated in
Figure 8. The mobile host is the host that has changed its locators, Figure 6. The mobile host is the host that has changed its locators,
and the peer host is the host it has a host association with. The and the peer host is the host it has a host association with. The
mobile host may have multiple peers and it repeats the process with mobile host may have multiple peers and it repeats the process with
all of its peers. In the figure, the HIP relay belongs to the peer all of its peers. In the figure, the HIP relay belongs to the peer
host, i.e., the peer host is a relay client for the HIP relay. It is host, i.e., the peer host is a relay client for the HIP relay. It is
worth noting that the figure corresponds to figure 3 in Figure 8, but worth noting that the figure corresponds to figure 3 in Figure 6, but
the difference is that the main UPDATE procedure is carried over the the difference is that the main UPDATE procedure is carried over the
relay and the connectivity is tested separately. Next, we describe relay and the connectivity is tested separately. Next, we describe
the procedure in the figure in detail. the procedure in the figure in detail.
Mobile Host HIP relay Peer Host Mobile Host HIP relay Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
| LOC_SET, SEQ)) | | | LOC_SET, SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | LOC_SET, SEQ, | | | LOC_SET, SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
skipping to change at page 26, line 34 skipping to change at page 23, line 42
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| 7. connectivity checks over UDP | | 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 8. ESP data over UDP | | 8. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
Figure 8: HIP UPDATE procedure Figure 6: HIP UPDATE procedure
In step 1, the mobile host has changed location and sends a location In step 1, the mobile host has changed location and sends a location
update to its peer through the HIP relay of the peer. It sends an update to its peer through the HIP relay of the peer. It sends an
UPDATE packet with source HIT belonging to itself and destination HIT UPDATE packet with source HIT belonging to itself and destination HIT
belonging to the peer host. In the packet, the source IP address belonging to the peer host. In the packet, the source IP address
belongs to the mobile host and the destination to the HIP relay. The belongs to the mobile host and the destination to the HIP relay. The
packet contains an ESP_INFO parameter, where, in this case, the OLD packet contains an ESP_INFO parameter, where, in this case, the OLD
SPI and NEW SPI parameters both contain the pre-existing incoming SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The packet also contains the locators of the mobile host in a SPI. The packet also contains the locators of the mobile host in a
LOCATOR_SET parameter. The packet contains also a SEQ number to be LOCATOR_SET parameter. The packet contains also a SEQ number to be
skipping to change at page 27, line 35 skipping to change at page 24, line 43
address of the HIP relay. The mobile host can start connectivity address of the HIP relay. The mobile host can start connectivity
checks after this packet. checks after this packet.
In step 6, HIP relay receives the UPDATE packet and forwards it to In step 6, HIP relay receives the UPDATE packet and forwards it to
the peer host (i.e. relay client). The HIP relay rewrites the the peer host (i.e. relay client). The HIP relay rewrites the
destination IP address and appends a RELAY_FROM parameter to the destination IP address and appends a RELAY_FROM parameter to the
message. When the peer host receives this concluding UPDATE packet, message. When the peer host receives this concluding UPDATE packet,
it can initiate the connectivity checks. it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according In step 7, the two hosts test for connectivity across NATs according
to procedures described in in section Section 4.6. The original to procedures described in Section 4.6. The original Initiator of
Initiator of the communications is the controlling and the original the communications is the controlling and the original Responder is
Responder is the controlled host. The controlling host SHOULD employ the controlled host.
the same mode as earlier for the base exchange (i.e. aggressive or
normal mode).
In step 8, the connectivity checks are successfully completed and the In step 8, the connectivity checks are successfully completed and the
controlling host has nominated one address pair to be used. The controlling host has nominated one address pair to be used. The
hosts set up security associations to deliver the application hosts set up security associations to deliver the application
payload. payload.
If either host has registered a relayed address candidate from a data
relay, the host MUST reactivate the address before connectivity
checks by sending an UPDATE message containing PEER_PERMISSION
parameter as described in Section 4.12.1. Otherwise, the relay drops
ESP packets using the relayed address.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts send
periodic keepalives to other hosts that they have established a host periodic keepalives to other hosts that they have established a host
associating with. If a registered host has not sent any data or associating with. If a registered host has not sent any data or
control messages to its HIP or data relay for 15 seconds, it MUST control messages to its HIP or data relay for 15 seconds, it MUST
send a HIP NOTIFY packet to the relay. Likewise, if a host has not send a HIP NOTIFY packet to the relay. Likewise, if a host has not
sent any data to another host it has established a host association sent any data to another host it has established a host association
in the ICE-HIP_UDP mode, it MUST send either a HIP NOTIFY packet or in the ICE-HIP_UDP mode, it MUST send either a HIP NOTIFY packet or
an ICMPv6 echo request inside the related ESP tunnel. HIP relay an ICMPv6 echo request inside the related ESP tunnel. HIP relay
servers MAY refrain from sending keepalives if it's known that they servers MAY refrain from sending keepalives if it's known that they
are not behind a middlebox that requires keepalives. If the base are not behind a middlebox that requires keepalives. If the base
exchange or mobility handover procedure occurs during an extremely exchange or mobility handover procedure occurs during an extremely
slow path, a host MAY also send HIP notify packets every 15 seconds slow path, a host MAY also send HIP notify packets every 15 seconds
to keep to path active. to keep to path active.
4.11. Close Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP and the related security The two-way procedure for closing a HIP and the related security
associations is defined in [RFC7401]. One hosts initiates the associations is defined in [RFC7401]. One hosts initiates the
procedure by sending a CLOSE party and the recipient confirms it with procedure by sending a CLOSE party and the recipient confirms it with
CLOSE_ACK. All packets are protected using HMACs and signatures, and CLOSE_ACK. All packets are protected using HMACs and signatures, and
the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to
protect against replay attacks. protect against replay attacks.
The same procedure for closing HIP associations applies also here, The same procedure for closing HIP associations applies also here,
but the messaging occurs using the UDP encapsulated tunnel that the but the messaging occurs using the UDP encapsulated tunnel that the
skipping to change at page 28, line 37 skipping to change at page 25, line 50
it MUST send over a HIP relay of the recipient if one exists. The it MUST send over a HIP relay of the recipient if one exists. The
host receiving the CLOSE message directly without a relay SHOULD host receiving the CLOSE message directly without a relay SHOULD
respond directly. The the CLOSE message came via a relay, it SHOULD respond directly. The the CLOSE message came via a relay, it SHOULD
respond using the same relay. respond using the same relay.
4.12. Relaying Considerations 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions 4.12.1. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before any ESP data packets sent by a peer are forwarded, a before the data relay forwards any ESP data packets from a peer to a
permission MUST be set for the peer's address. The permissions also registered host (or the other direction), the client MUST set a
install a forwarding rule, similar to TURN's channels, based on the permission for the peer's address. The permissions also install a
Security Parameter Index (SPI) values in the ESP packets. forwarding rule for each direction, similar to TURN's channels, based
on the Security Parameter Index (SPI) values in the ESP packets.
Permissions are not required for the connectivity checks, but if a Permissions are not required for HIP control packets. However, if a
relayed address is selected to be used for data, the registered host relayed address (as conveyed in the RELAYED_ADDRESS parameter from
MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION the data relay) is selected to be used for data, the registered host
parameter (see Section 5.13) with the address of the peer and the MUST send an UPDATE message to the data relay containing a
outbound and inbound SPI values the host is using with this peer. PEER_PERMISSION parameter (see Section 5.13) with the address of the
peer, and the outbound and inbound SPI values the registered host is
using with this particular peer. To avoid packet dropping of ESP
packets, the registered host SHOULD send the PEER_PERMISSION
parameter before connectivity checks both in the case of base
exchange and a mobility handover. It is worth noting that the UPDATE
message includes a SEQ parameter (as specified in [RFC7401]) that the
data relay must acknowledge, so that the registered host can resend
the message with PEER_PERMISSION parameter if it gets lost.
When a data relay receives an UPDATE with a PEER_PERMISSION When a data relay receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the relay checks if there is registered. If the host was registered, the relay checks if there is
a permission with matching information (address, protocol, port and a permission with matching information (address, protocol, port and
SPI values). If there is no such permission, a new permission MUST SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
permissions 1 minute before the expiration if the permission is still permissions 1 minute before the expiration when the permission is
needed. still needed.
4.12.2. Relaying UDP Encapsulated Data and Control Packets The relayed address MUST be activated with the PEER_PERMISSION
parameter both after the base exchange and after a handover. Unless
activated, the data relay MUST drop all ESP packets.
When a HIP data relay accepts to relay UDP encapsulated data, it 4.12.2. Relaying UDP Encapsulated Control and Data Packets
opens a UDP port (relayed address) for this purpose as described in
Section 4.1. If the data relay receives a UDP encapsulated HIP
control packet on that port, it MUST forward the packet to the
registered host and add a RELAY_FROM parameter to the packet as if
the data relay was acting as a HIP relay server [RFC5770].
When a host wants to send a HIP control packet (such as a When a HIP data relay accepts to relay UDP encapsulated ESP between a
connectivity check packet) to a peer via the data relay, it MUST add registered host and its peer, the relay opens a UDP port (relayed
a RELAY_TO parameter containing the peer's address to the packet and address) for this purpose as described in Section 4.1. This port can
send it to the data relay's address. The data relay MUST send the be used for delivering also control packets because connectivity
packet to the peer's address from the relayed address. checks also cover the path through the data relay. If the data relay
receives a UDP encapsulated HIP control packet on that port, it MUST
forward the packet to the registered host and add a RELAY_FROM
parameter to the packet as if the data relay was acting as a HIP
relay server. When the registered host replies to a control packet
with a RELAY_FROM parameter via its relay, the registered host MUST
add a RELAY_TO parameter containing the peer's address and use the
address of its data relay as the destination address. Further, the
data relay MUST send this packet to the peer's address from the
relayed address.
If the data relay receives a UDP packet that is not a HIP control If the data relay receives a UDP packet that is not a HIP control
packet to the relayed address, it MUST check whether there is a packet to the relayed address, it MUST check if it has a permission
permission set for the peer the packet is coming from (i.e., the set for the peer the packet is arriving from (i.e., the sender's
sender's address and SPI value matches to an installed permission), address and SPI value matches to an installed permission). If
and if there is, it MUST forward the packet to the registered host permissions are set, the data relay MUST forward the packet to the
that created the permission. Packets without a permission MUST be registered host that created the permission. The data relay MUST
dropped silently. also implement the similar checks for the reverse direction (i.e.
ESP packets from the registered host to the peer). Packets without a
When a host wants to send a UDP encapsulated ESP packet to a peer via permission MUST be dropped silently.
the data relay, it MUST have an active permission at the data relay
for the peer with the outbound SPI value it is using. The host MUST
send the UDP encapsulated ESP packet to the data relay's address.
When the data relay receives a UDP encapsulated ESP packet from a
registered host, it MUST check whether there exists a permission for
that outbound SPI value. If such permission exists, the packet MUST
be forwarded to the address that was registered for the SPI value.
If no permission exists, the packet is dropped.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
Since the HIP data relay determines from the SPI value to which peer The inbound SPI values of the registered clients should be unique so
an ESP packet should be forwarded, the outbound SPI values need to be that a data relay can properly demultiplex incoming packets from peer
unique for each relayed address registration. Thus, if a registered hosts to the correct registered clients. Vice versa, the inbound
host detects that a peer would use an SPI value that is already used SPIs of the peer hosts should be unique for the same reason. These
with another peer via the relay, it MUST NOT select the relayed two cases are discussed in this section separately.
address for use. The host MAY restart the base exchange to avoid a
conflict or it MAY refrain from using the relayed candidate for the
connectivity checks.
Since the SPI space is 32 bits and the SPI values should be random, In first case, the SPI collision problem occurs when two Initiators
the probability for a conflicting SPI value is fairly small. run a base exchange to the same Responder (i.e. registered host), and
However, a host with many peers MAY decrease the odds of a conflict both the Initiators claim the same inbound SPI. Upon receiving an I2
by registering more than one relayed address using different local with a colliding SPI, the Responder MUST not include the relayed
addresses. address in the R2 message because the data relay would not be able
demultiplex the related ESP packet to the correct Initiator. Since
the SPI space is 32 bits and the SPI values should be random, the
probability for a conflicting SPI value is fairly small. However, a
registered host with many peers MAY proactively decrease the odds of
a conflict by registering to multiple data relays. The described
collision scenario can be avoided if the Responder delivers a new
relayed address candidate upon SPI collisions. Each relayed address
has a separate UDP port reserved to it, so the relay can demultiplex
properly conflicting SPIs of the Initiators based on the SPI and port
number towards the correct Responder.
In the second case, the SPI collision problems occurs if two hosts
have registered to the same data relay and a third host initiates
base exchange with both of them. In this case, the data relay has
allocated separate UDP ports for the two registered hosts acting now
as Responders. When the Responders send identical SPI values in
their I2 messages via the relay, it can properly demultiplex it to
the correct Responder because the UDP ports are different.
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be in network byte for the HIP and ESP packets. All values MUST be in network byte
order. order.
It is worth noting that most of the parameters are shown for It is worth noting that most of the parameters are shown for
completeness sake even though they are specified already in completeness sake even though they are specified already in
[RFC5770]. New parameters are explicitly described as new. [RFC5770]. New parameters are explicitly described as new.
5.1. HIP Control Packets 5.1. HIP Control Packets
Figure Figure 9 illustrates the packet format for UDP-encapsulated Figure 7 illustrates the packet format for UDP-encapsulated HIP. The
HIP. The format is identical to [RFC5770]. format is identical to [RFC5770].
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 9: Format of UDP-Encapsulated HIP Control Packets Figure 7: 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], "IKE Header Format for Port 4500", except a Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a
different port number is used. Figure 9 illustrates the different port number is used. Figure 7 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 [RFC7401] with HIP header and parameters follow the conventions of [RFC7401] 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
already contains a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC7401] includes the IP addresses in the checksum calculation. The [RFC7401] 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.
skipping to change at page 31, line 31 skipping to change at page 29, line 20
5.3. Keepalives 5.3. Keepalives
The keepalives are either HIP NOTIFY packets as specified in The keepalives are either HIP NOTIFY packets as specified in
[RFC7401] or ICMPv6 packets inside the ESP tunnel. [RFC7401] or ICMPv6 packets inside the ESP tunnel.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from The format of NAT traversal mode parameter is borrowed from
[RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar
to the format of the ESP_TRANSFORM parameter in [RFC7402] and is to the format of the ESP_TRANSFORM parameter in [RFC7402] and is
shown in Figure 10. This specification defines traversal mode shown in Figure 8. This specification defines traversal mode
identifier for ICE-HIP-UDP. The identifier RESERVED is reserved for identifier for ICE-HIP-UDP. The identifier RESERVED is reserved for
future use. Future specifications may define more traversal modes. 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 | | Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 28 skipping to change at page 29, line 47
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
Mode ID defines the proposed or selected NAT traversal mode(s) Mode ID defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined: The following NAT traversal mode IDs are defined:
ID name Value ID name Value
RESERVED 0 RESERVED 0
ICE-HIP-UDP 3 ICE-HIP-UDP 3
Figure 10: Format of the NAT_TRAVERSAL_MODE Parameter Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that 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 there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. Conversely, a recipient MUST be prepared to handle parameter. Conversely, a recipient MUST be prepared to handle
received NAT traversal mode parameters that contain more than six received NAT traversal mode parameters that contain more than six
Mode IDs by accepting the first six Mode IDs and dropping the rest. Mode IDs by accepting the first six Mode IDs and dropping the rest.
The limited number of Mode IDs sets the maximum size of the The limited number of Mode IDs sets the maximum size of the
NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order,
most preferred mode(s) first. most preferred mode(s) first.
5.5. Connectivity Check Transaction Pacing Parameter 5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING is a new parameter, and it shown in Figure 11 The TRANSACTION_PACING is a new parameter, and it shown in Figure 9
contains only the connectivity check pacing value, expressed in contains only the connectivity check pacing value, expressed in
milliseconds, as a 32-bit unsigned integer. milliseconds, as a 32-bit unsigned integer.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta | | Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 610 Type 610
Length 4 Length 4
Min Ta the minimum connectivity check transaction pacing Min Ta the minimum connectivity check transaction pacing
value the host would use value the host would use
Figure 11: Format of the TRANSACTION_PACING Parameter Figure 9: Format of the TRANSACTION_PACING Parameter
5.6. Relay and Registration Parameters 5.6. Relay and Registration Parameters
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
shown in Figure 12. All parameters are identical except for the shown in Figure 10. All parameters are identical except for the
type. REG_FROM is the only parameter covered with the signature. type. REG_FROM is the only parameter covered with the signature.
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 | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 33, line 51 skipping to change at page 31, line 30
RELAY_TO: 64002 RELAY_TO: 64002
Length 20 Length 20
Port transport port number; zero when plain IP is used Port transport port number; zero when plain IP is used
Protocol IANA assigned, Internet Protocol number. Protocol IANA assigned, Internet Protocol number.
17 for UDP, 0 for plain IP 17 for UDP, 0 for plain IP
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 12: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO
Parameters Parameters
REG_FROM contains the transport address and protocol from which the REG_FROM contains the transport address and protocol from which the
HIP relay server sees the registration coming. RELAY_FROM contains HIP relay server sees the registration coming. RELAY_FROM contains
the address from which the relayed packet was received by the relay the address from which the relayed packet was received by the relay
server and the protocol that was used. RELAY_TO contains the same server and the protocol that was used. RELAY_TO contains the same
information about the address to which a packet should be forwarded. information about the address to which a packet should be forwarded.
5.7. LOCATOR_SET Parameter 5.7. LOCATOR_SET Parameter
This specification reuses the format for UDP-based locators specified This specification reuses the format for UDP-based locators specified
in [RFC5770] to be used for communicating the address candidates in [RFC5770] to be used for communicating the address candidates
between two hosts. The generic and NAT-traversal-specific locator between two hosts. The generic and NAT-traversal-specific locator
parameters are illustrated in Figure 13. parameters are illustrated in Figure 11.
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 34, line 51 skipping to change at page 32, line 38
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | | Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: LOC_SET Parameter Figure 11: LOC_SET Parameter
The individual fields in the LOCATOR_SET parameter are described in The individual fields in the LOCATOR_SET parameter are described in
Table 1. Table 1.
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
| 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 |
skipping to change at page 35, line 34 skipping to change at page 33, line 31
| 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 | Variable | IANA assigned, transport layer Internet | | Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. | | | | 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 |
| | | [RFC5245] | | | | [I-D.ietf-ice-rfc5245bis] |
| SPI | Variable | Security Parameter Index (SPI) value that | | SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP | | | | the host expects to see in incoming ESP |
| | | packets that use this locator | | | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 1: Fields of the LOCATOR_SET Parameter Table 1: Fields of the LOCATOR_SET Parameter
5.8. RELAY_HMAC Parameter 5.8. RELAY_HMAC Parameter
skipping to change at page 37, line 20 skipping to change at page 35, line 14
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 [RFC7402]. The UDP encapsulation format and processing of defined in [RFC7402]. The UDP encapsulation format and processing of
HIP ESP traffic is described in Section 6.1 of [RFC7402]. HIP ESP traffic is described in Section 6.1 of [RFC7402].
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
While the type values are new, the format of the RELAYED_ADDRESS and While the type values are new, the format of the RELAYED_ADDRESS and
MAPPED_ADDRESS parameters (Figure 14) is identical to REG_FROM, MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM,
RELAY_FROM and RELAY_TO parameters. This document specifies only use RELAY_FROM and RELAY_TO parameters. This document specifies only the
of UDP relaying, and, thus, only protocol 17 is allowed. However, use of UDP relaying, and, thus, only protocol 17 is allowed.
future documents may specify support for other protocols. However, future documents may specify support for other protocols.
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 | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
skipping to change at page 37, line 49 skipping to change at page 35, line 43
RELAYED_ADDRESS: 4650 RELAYED_ADDRESS: 4650
MAPPED_ADDRESS: 4660] MAPPED_ADDRESS: 4660]
Length 20 Length 20
Port the UDP port number Port the UDP port number
Protocol IANA assigned, Internet Protocol number (17 for UDP) Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 14: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS
Parameters Parameters
5.13. PEER_PERMISSION Parameter 5.13. PEER_PERMISSION Parameter
The format of the new PEER_PERMISSION parameter is shown in The format of the new PEER_PERMISSION parameter is shown in
Figure 15. The parameter is used for setting up and refreshing Figure 13. The parameter is used for setting up and refreshing
forwarding rules and permissions at the data relay for data packets. forwarding rules and the permissions for data packets at the data
The parameter contains one or more sets of Port, Protocol, Address, relay. The parameter contains one or more sets of Port, Protocol,
Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set defines Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set
a rule for one peer address. defines a rule for one peer address.
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 | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
skipping to change at page 38, line 48 skipping to change at page 36, line 41
Protocol IANA assigned, Internet Protocol number (17 for UDP) Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address, or an IPv4 address in "IPv4-Mapped Address an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer IPv6 address" format, of the peer
OSPI the outbound SPI value the registered host is using for OSPI the outbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
ISPI the inbound SPI value the registered host is using for ISPI the inbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
Figure 15: Format of the PEER_PERMISSION Parameter Figure 13: Format of the PEER_PERMISSION Parameter
5.14. HIP Connectivity Check Packets 5.14. HIP Connectivity Check Packets
The connectivity request messages are HIP UPDATE packets containing a The connectivity request messages are HIP UPDATE packets containing a
new CANDIDATE_PRIORITY parameter (Figure 16). Response UPDATE new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE
packets contain a MAPPED_ADDRESS parameter (Figure 14). packets contain a MAPPED_ADDRESS parameter (Figure 12).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4700] Type [TBD by IANA; 4700]
Length 4 Length 4
Priority the priority of a (potential) peer reflexive candidate Priority the priority of a (potential) peer reflexive candidate
Figure 16: Format of the CANDIDATE_PRIORITY Parameter Figure 14: Format of the CANDIDATE_PRIORITY Parameter
5.15. NOMINATE parameter 5.15. NOMINATE parameter
Figure Figure 17 shows the NOMINATE parameter that is used to Figure 15 shows the NOMINATE parameter that is used to conclude the
conclude the candidate nomination process. candidate nomination process.
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 | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4710] Type [TBD by IANA; 4710]
Length 4 Length 4
Reserved Reserved for future extension purposes Reserved Reserved for future extension purposes
Figure 17: Format of the NOMINATE Parameter Figure 15: Format of the NOMINATE Parameter
6. Security Considerations 6. Security Considerations
The security considerations are the same as in [RFC5770], but are The security considerations are the same as in [RFC5770], but are
repeated here for completeness sake. repeated here for completeness sake.
6.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in plain text format in favor of inspection at HIP- The locators are in plain text format in favor of inspection at HIP-
aware middleboxes in the future. The current document does not aware middleboxes in the future. The current document does not
skipping to change at page 41, line 24 skipping to change at page 39, line 14
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 uses HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
6.5. Reuse of Ports at the Data Relay 6.5. Reuse of Ports at the Data Relay
If the data relay uses the same relayed address and port for multiple If the data relay uses the same relayed address and port (as conveyed
registered hosts, it appears to all the peers, and their firewalls, in the RELAYED_ADDRESS parameter) for multiple registered hosts, it
that all the registered hosts using the relay are at the same appears to all the peers, and their firewalls, that all the
address. Thus, a stateful firewall may allow packets pass from hosts registered hosts using the relay are at the same address. Thus, a
that would not normally be able to send packets to a peer behind the stateful firewall may allow packets pass from hosts that would not
firewall. Therefore, a HIP data relay SHOULD NOT re-use the port normally be able to send packets to a peer behind the firewall.
numbers. If port numbers need to be re-used, the relay SHOULD have a Therefore, a HIP data relay SHOULD NOT re-use the port numbers. If
sufficiently large pool of port numbers and select ports from the port numbers need to be re-used, the relay SHOULD have a sufficiently
pool randomly to decrease the chances of a registered host obtaining large pool of port numbers and select ports from the pool randomly to
the same address that a another host behind the same firewall is decrease the chances of a registered host obtaining the same address
using. that a another host behind the same firewall is using.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC7401] by assigning new HIP Parameter Type values for the new HIP [RFC7401] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in
Section 5.12), and PEER_PERMISSION (defined in Section 5.13). Section 5.12), and PEER_PERMISSION (defined in Section 5.13).
This document also updates the IANA Registry for HIP NAT traversal This document also updates the IANA Registry for HIP NAT traversal
modes [RFC5770] by assigning value for the NAT traversal mode ICE- modes [RFC5770] by assigning value for the NAT traversal mode ICE-
HIP-UDP (defined in XX FIXME target="sec:hip-nat-traversal-mode". HIP-UDP (defined in Section 5.4).
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow
registering with a HIP relay server for ESP relaying service: registering with a HIP relay server for ESP relaying service:
RELAY_UDP_ESP (defined in Section 4.1; and performing server RELAY_UDP_ESP (defined in Section 4.1; and performing server
reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in
Section 4.2). Section 4.2).
8. Contributors 8. Contributors
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in contributed to [RFC5770]. This document leans heavily on the work in
the RFC. the RFC.
skipping to change at page 42, line 27 skipping to change at page 40, line 17
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks to 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, and Abhinav Pathak for their contributions and Tobias Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian
Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka
Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and
Jani Hautakorpi for their comments to [RFC5770], which is the basis Jani Hautakorpi for their comments to [RFC5770], which is the basis
for this document. for this document.
This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>.
[I-D.ietf-hip-rfc5203-bis] [I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-10 Registration Extension", draft-ietf-hip-rfc5203-bis-10
(work in progress), January 2016. (work in progress), January 2016.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), December 2015. in progress), December 2015.
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12
(work in progress), May 2016. (work in progress), May 2016.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5766] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP) Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators", Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010, RFC 5770, DOI 10.17487/RFC5770, April 2010,
<http://www.rfc-editor.org/info/rfc5770>. <http://www.rfc-editor.org/info/rfc5770>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>. <http://www.rfc-editor.org/info/rfc5389>.
skipping to change at page 44, line 5 skipping to change at page 41, line 31
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[I-D.ietf-ice-rfc5245bis]
Ker&#52292;nen, A., Holmberg, C., and J. Rosenberg,
"Interactive Connectivity Establishment (ICE): A Protocol
for Network Address Translator (NAT) Traversal", draft-
ietf-ice-rfc5245bis-03 (work in progress), June 2016.
10.2. Informative References 10.2. Informative References
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, Henderson, "Host Identity Protocol", RFC 5201,
DOI 10.17487/RFC5201, April 2008, DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>. <http://www.rfc-editor.org/info/rfc5201>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, DOI 10.17487/RFC5207, April Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <http://www.rfc-editor.org/info/rfc5207>. 2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[MMUSIC-ICE] [MMUSIC-ICE]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", Work in Progress, July 2008. Protocol (SIP) Protocols", Work in Progress, July 2008.
[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, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
 End of changes. 76 change blocks. 
347 lines changed or deleted 279 lines changed or added

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