draft-ietf-hip-native-nat-traversal-27.txt   draft-ietf-hip-native-nat-traversal-28.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: June 23, 2018 Ericsson Expires: September 6, 2018 Ericsson
December 20, 2017 March 5, 2018
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-27 draft-ietf-hip-native-nat-traversal-28
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 June 23, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9
4.2. Transport Address Candidate Gathering at the Relay Client 13 4.2. Transport Address Candidate Gathering at the Relay Client 13
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17
4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 39 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 39
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 40 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 40
5.6. Relay and Registration Parameters . . . . . . . . . . . . 41 5.6. Relay and Registration Parameters . . . . . . . . . . . . 41
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 44 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 44 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 45 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 45 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 46 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 47 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 48 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 48 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 49
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 49 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50
6.3. Base Exchange Replay Protection for Control Relay Server 49 6.3. Base Exchange Replay Protection for Control Relay Server 50
6.4. Demultiplexing Different HIP Associations . . . . . . . . 50 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 50 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 50 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 50 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 54 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 56
Appendix B. Differences with respect to ICE . . . . . . . . . . 55 Appendix B. Differences with respect to ICE . . . . . . . . . . 56
Appendix C. Differences to Base Exchange and UPDATE procedures . 56 Appendix C. Differences to Base Exchange and UPDATE procedures . 58
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 59 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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
skipping to change at page 4, line 46 skipping to change at page 4, line 46
modifies it to be compatible with ICE. The differences to the modifies it to be compatible with ICE. The differences to the
mobility extensions specified in Appendix C. It is worth noting that mobility extensions specified in Appendix C. It is worth noting that
multihoming support as specified in [RFC8047] is left for further multihoming support as specified in [RFC8047] is left for further
study. study.
This specification builds heavily on the ICE methodology, so it is This specification builds heavily on the ICE methodology, so it is
recommended that the reader is familiar with the ICE specification recommended that the reader is familiar with the ICE specification
[I-D.ietf-ice-rfc5245bis] (especially the overview). However, native [I-D.ietf-ice-rfc5245bis] (especially the overview). However, native
ICE-HIP does not implement all the features in ICE, and, hence, the ICE-HIP does not implement all the features in ICE, and, hence, the
different features of ICE are cross referenced using [RFC2119] different features of ICE are cross referenced using [RFC2119]
terminology for clarity. Appendix B explains the differences to ICE. terminology for clarity. Appendix B explains the differences to ICE,
and it is recommended that the reader would read also this section in
addition to the ICE specification.
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],
[RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The
following terms recur in the text: following terms recur in the text:
skipping to change at page 6, line 13 skipping to change at page 6, line 19
servers. servers.
Data Relay Client: Data Relay Client:
A requester host that registers to a Data Relay Server requesting A requester host that registers to a Data Relay Server requesting
it to forward data-plane traffic (e.g. ESP traffic). it to forward data-plane traffic (e.g. ESP traffic).
Locator: Locator:
As defined in [RFC8046]: "A name that controls how the packet is As defined in [RFC8046]: "A name that controls how the packet is
routed through the network and demultiplexed by the end-host. It routed through the network and demultiplexed by the end-host. It
may include a concatenation of traditional network addresses such may include a concatenation of traditional network addresses such
as an IPv6 address and end-to-end identifiers such as an ESP SPI. as an IPv6 address and end-to-end identifiers such as an ESP
It may also include transport port numbers or IPv6 Flow Labels as Security Parameter Index (SPI). It may also include transport
demultiplexing context, or it may simply be a network address." port numbers or IPv6 Flow Labels as demultiplexing context, or it
may simply be a network address."
LOCATOR_SET (written in capital letters): LOCATOR_SET (written in capital letters):
Denotes a HIP control packet parameter that bundles multiple Denotes a HIP control packet parameter that bundles multiple
locators together. locators together.
ICE offer: ICE offer:
The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. The Initiator's LOCATOR_SET parameter in a HIP I2 control packet.
Corresponds to the ICE offer parameter, but is HIP specific. Corresponds to the ICE offer parameter, but is HIP specific.
ICE answer: ICE answer:
skipping to change at page 7, line 32 skipping to change at page 7, line 39
Client. Client.
Permission: Permission:
In the context of Data Relay Server, permission refers to a In the context of Data Relay Server, permission refers to a
concept similar to TURN's channels. Before a host can use a concept similar to TURN's channels. Before a host can use a
relayed candidate to forward traffic through a Data Relay Server, relayed candidate to forward traffic through a Data Relay Server,
the host must activate the relayed candidate with a specific peer the host must activate the relayed candidate with a specific peer
host. host.
Base: Base:
The base of an candidate is the local source address a host uses The base of a candidate is the local source address a host uses to
to send packets for the associated candidate. For example, the send packets for the associated candidate. For example, the base
base of a server reflexive address is the local address the host of a server reflexive address is the local address the host used
used for registering itself to the associated Control or Data for registering itself to the associated Control or Data Relay
Relay Server. The base of a host candidate is equal to the host Server. The base of a host candidate is equal to the host
candidate itself. candidate itself.
3. Overview of Operation 3. Overview of Operation
+--------------+ +--------------+
| Control | | Control |
+--------+ | Relay Server | +--------+ +--------+ | Relay Server | +--------+
| Data | +----+-----+---+ | Data | | Data | +----+-----+---+ | Data |
| Relay | / \ | Relay | | Relay | / \ | Relay |
| Server | / \ | Server | | Server | / \ | Server |
+--------+ / \ +--------+ +--------+ / \ +--------+
skipping to change at page 8, line 35 skipping to change at page 8, line 35
Figure 1: Example Network Configuration Figure 1: Example Network Configuration
In the example configuration depicted in Figure 1, both Initiator and In the example configuration depicted in Figure 1, both Initiator and
Responder are behind one or more NATs, and both private networks are Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
at least the Responder must be registered with a Control Relay Server at least the Responder must be registered with a Control Relay Server
reachable on the public Internet. The Responder may have also reachable on the public Internet. The Responder may have also
registered to a Data Relay Server that can forward the data plane in registered to a Data Relay Server that can forward the data plane in
case NAT traversal fails. While, strictly speaking, the Initiator case NAT traversal fails. While, strictly speaking, the Initiator
does not need any Relay Servers, it may act in the other role for does not need any Relay Servers, it may act in the other role with
other hosts and connectivity with the Data Relay Server of the other hosts, and connectivity with the Data Relay Server of the
Responder may fail, so it is the Initiator may also have registered Responder may fail, so the Initiator may also need to register to a
to a Control and/or Data Relay Server. It is worth noting that a Cotrol and/or Data Relay Server. It is worth noting that a Control
Control and Data Relay does not forge the source address of a passing and Data Relay does not forge the source address of a passing packet,
packet, but always translates the source address and source port of a but always translates the source address and source port of a packet
packet to be forwarded (to its own). to be forwarded (to its own).
We assume, as a starting point, that the Initiator knows both the We assume, as a starting point, that the Initiator knows both the
Responder's Host Identity Tag (HIT) and the address(es) of the Responder's Host Identity Tag (HIT) and the address(es) of the
Responder's Control Relay Server(s) (how the Initiator learns of the Responder's Control Relay Server(s) (how the Initiator learns of the
Responder's Control Relay Server is outside of the scope of this Responder's Control Relay Server is outside of the scope of this
document, but may be through DNS or another name service). The first document, but may be through DNS or another name service). The first
steps are for both the Initiator and Responder to register with a steps are for both the Initiator and Responder to register with a
Control Relay Server (need not be the same one) and gather a set of Control Relay Server (need not be the same one) and gather a set of
address candidates. The hosts use either Control Relay Servers or address candidates. The hosts use either Control Relay Servers or
Data Relay Servers (or other infrastructure including STUN or TURN Data Relay Servers for gathering the candidates. Next, the HIP base
servers) for gathering the candidates. Next, the HIP base exchange exchange is carried out by encapsulating the HIP control packets in
is carried out by encapsulating the HIP control packets in UDP UDP datagrams and sending them through the Responder's Control Relay
datagrams and sending them through the Responder's Control 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. embedded in the base exchange.
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 Control Relay working communication session (for signaling) via a Control Relay
Server, but the hosts still have to find a better path, preferably Server, but the hosts still have to find a better path, preferably
without a Data Relay Server, for the ESP data flow. For this, without a Data Relay Server, for the ESP data flow. For this,
connectivity checks are carried out until a working pair of addresses connectivity checks are carried out until a working pair of addresses
is discovered. At the end of the procedure, if successful, the hosts is discovered. At the end of the procedure, if successful, the hosts
skipping to change at page 13, line 48 skipping to change at page 13, line 48
traversal. However, if no Data Relay Server is used, and the host traversal. However, if no Data Relay Server is used, and the host
has only a single local IP address to use, the host MAY use the local has only a single local IP address to use, the host MAY use the local
address as the only host candidate and the address from the REG_FROM address as the only host candidate and the address from the REG_FROM
parameter discovered during the Control Relay Server registration as parameter discovered during the Control Relay Server registration as
a server reflexive candidate. In this case, no further candidate a server reflexive candidate. In this case, no further candidate
gathering is needed. gathering is needed.
A Data Relay Client MAY register only a single relayed candidate to A Data Relay Client MAY register only a single relayed candidate to
be used with multiple other peers. However, it is RECOMMENDED that a be used with multiple other peers. However, it is RECOMMENDED that a
Data Relay Client registers a new server reflexive candidate for each Data Relay Client registers a new server reflexive candidate for each
its peer for the reasons described in Section 4.12.3. The procedures of its peer for the reasons described in Section 4.12.3. The
for registering multiple relayed candidates are described in procedures for registering multiple relayed candidates are described
Section 4.1. in Section 4.1.
If a Relay Client has more than one network interface, it can If a Relay Client has more than one network interface, it can
discover additional server reflexive candidates by sending UPDATE discover additional server reflexive candidates by sending UPDATE
messages from each of its interfaces to the Relay Server. Each such messages from each of its interfaces to the Relay Server. Each such
UPDATE message MUST include the following parameters: registration UPDATE message MUST include the following parameters: registration
request (REG_REQ) parameter with Registration Type request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED
parameter. When a Control Relay Server receives an UPDATE message parameter. When a Control Relay Server receives an UPDATE message
with registration request containing a CANDIDATE_DISCOVERY type, it with registration request containing a CANDIDATE_DISCOVERY type, it
MUST include a REG_FROM parameter, containing the same information as MUST include a REG_FROM parameter, containing the same information as
skipping to change at page 14, line 37 skipping to change at page 14, line 37
server providing both Control and Data Relay Server functionality, or server providing both Control and Data Relay Server functionality, or
one Control Relay Server and also Data Relay Server if the one Control Relay Server and also Data Relay Server if the
functionality is offered by another server. When the relay service functionality is offered by another server. When the relay service
is split between two hosts, the server reflexive candidate from the is split between two hosts, the server reflexive candidate from the
Control Relay Server SHOULD be used instead of the one provided by Control Relay Server SHOULD be used instead of the one provided by
the Data Relay Server. If a relayed candidate is identical to a host the Data Relay Server. If a relayed candidate is identical to a host
candidate, the relayed candidate must be discarded. NAT64 candidate, the relayed candidate must be discarded. NAT64
considerations in [I-D.ietf-ice-rfc5245bis] apply as well. considerations in [I-D.ietf-ice-rfc5245bis] apply as well.
HIP based connectivity can be utilized by IPv4 applications using HIP based connectivity can be utilized by IPv4 applications using
LSIs and by IPv6 based applications using HITs. The LSIs and HITs of Local Scope Identifiers (LSIs) and by IPv6 based applications using
the local virtual interfaces MUST be excluded in the candidate HITs. The LSIs and HITs of the local virtual interfaces MUST be
gathering phase as well to avoid creating unnecessary loopback excluded in the candidate gathering phase as well to avoid creating
connectivity tests. unnecessary loopback connectivity tests.
Gathering of candidates MAY also be performed by other means than Gathering of candidates MAY also be performed by other means than
described in this section. For example, the candidates could be described in this section. For example, the candidates could be
gathered as specified in Section 4.2 of [RFC5770] if STUN servers are gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
available, or if the host has just a single interface and no STUN or available, or if the host has just a single interface and no STUN or
Data Relay Server are available. Data Relay Server are available.
Each local address candidate MUST be assigned a priority. The Each local address candidate MUST be assigned a priority. The
following recommended formula (as described in following recommended formula (as described in
[I-D.ietf-ice-rfc5245bis]) SHOULD be used: [I-D.ietf-ice-rfc5245bis]) SHOULD be used:
skipping to change at page 15, line 37 skipping to change at page 15, line 37
Unlike ICE, this protocol only creates a single UDP flow between the Unlike ICE, this protocol only creates a single UDP flow between the
two communicating hosts, so only a single component exists. Hence, two communicating hosts, so only a single component exists. Hence,
the component ID value MUST always be set to 1. the component ID value MUST always be set to 1.
As defined in ICE , the retransmission timeout (RTO) for address As defined in ICE , the retransmission timeout (RTO) for address
gathering from a Control/Data Relay Server SHOULD be calculated as gathering from a Control/Data Relay Server SHOULD be calculated as
follows: follows:
RTO = MAX (500ms, Ta * (Num-Of-Pairs)) RTO = MAX (500ms, Ta * (Num-Of-Pairs))
where Ta is the value used for Ta is the value used for the where Ta is the value used for the connectivity check pacing and Num-
connectivity check pacing and Num-Of-Pairs is number of pairs of Of-Pairs is number of pairs of candidates with Control and Data Relay
candidates with Control and Data Relay Servers (e.g. in the case of a Servers (e.g. in the case of a single server, it would be 1). A
single server, it would be 1). A smaller value than 500 ms for the smaller value than 500 ms for the RTO MUST NOT be used.
RTO MUST NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical (as defined in document. As the parameter is non-critical (as defined in
Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which
means that the host is not required to support it or may decline to means that the host is not required to support it or may decline to
use it. use it.
skipping to change at page 20, line 49 skipping to change at page 20, line 49
in the ICE specification, the basic procedure for connectivity checks in the ICE specification, the basic procedure for connectivity checks
has three phases: sorting the candidate pairs according their has three phases: sorting the candidate pairs according their
priority, sending checks in the prioritized order and acknowledging priority, sending checks in the prioritized order and acknowledging
the checks from the peer host. the checks from the peer host.
The Initiator MUST take the role of controlling host and the The Initiator MUST take the role of controlling host and the
Responder acts as the controlled host. The roles MUST persist Responder acts as the controlled host. The roles MUST persist
throughout the HIP associate lifetime (to be reused in the possibly throughout the HIP associate lifetime (to be reused in the possibly
mobility UPDATE procedures). In the case both communicating nodes mobility UPDATE procedures). In the case both communicating nodes
are initiating the communications to each other using an I1 packet, are initiating the communications to each other using an I1 packet,
the conflict is resolved as defined in section in 6.7 in [RFC7401]: the conflict is resolved as defined in section 6.7 in [RFC7401]: the
the host with the "larger" HIT changes to its Role to Responder. In host with the "larger" HIT changes to its Role to Responder. In such
such a case, the host changing its role to Responder MUST also switch a case, the host changing its role to Responder MUST also switch to
to controlling role. controlling role.
The protocol follows standard HIP UPDATE sending and processing rules The protocol follows standard HIP UPDATE sending and processing rules
as defined in section 6.11 and 6.12 in [RFC7401], but some new as defined in section 6.11 and 6.12 in [RFC7401], but some new
parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and
NOMINATE). NOMINATE).
4.6.1. Connectivity Check Procedure 4.6.1. Connectivity Check Procedure
Figure 5 illustrates connectivity checks in a simplified scenario, Figure 5 illustrates connectivity checks in a simplified scenario,
where the Initiator and Responder have only a single candidate pair where the Initiator and Responder have only a single candidate pair
skipping to change at page 25, line 47 skipping to change at page 25, line 47
candidates are not used. From viewpoint of the ICE specification candidates are not used. From viewpoint of the ICE specification
[I-D.ietf-ice-rfc5245bis], the protocol specified in this document [I-D.ietf-ice-rfc5245bis], the protocol specified in this document
operates using Component ID of 1 on all candidates, and the operates using Component ID of 1 on all candidates, and the
foundation of all candidates is unique. This specification defines foundation of all candidates is unique. This specification defines
only "full ICE" mode, and the "lite ICE" is not supported. The only "full ICE" mode, and the "lite ICE" is not supported. The
reasoning behind the missing features is described in Appendix B. reasoning behind the missing features is described in Appendix B.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
neither one of the hosts announced a minimum pacing value, a value of neither one of the hosts announced a minimum pacing value, a value of
20 ms SHOULD be used. 50 ms SHOULD be used.
Both hosts MUST form a priority ordered checklist and begin to check Both hosts MUST form a priority ordered checklist and begin to check
transactions every Ta milliseconds as long as the checks are running transactions every Ta milliseconds as long as the checks are running
and there are candidate pairs whose tests have not started. The and there are candidate pairs whose tests have not started. The
retransmission timeout (RTO) for the connectivity check UPDATE retransmission timeout (RTO) for the connectivity check UPDATE
packets SHOULD be calculated as follows: packets SHOULD 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
skipping to change at page 39, line 16 skipping to change at page 39, line 16
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 that are unaware of HIP cannot recompute the HIP checksum after NATs that are unaware of HIP cannot recompute the HIP checksum after
changing IP addresses. changing IP addresses.
A Control/Data Relay Server or a non-relay Responder SHOULD listen at A Control/Data Relay Server or a non-relay Responder SHOULD listen at
UDP port 10500 for incoming UDP-encapsulated HIP control packets. If UDP port 10500 for incoming UDP-encapsulated HIP control packets. If
some other port number is used, it needs to be known by potential some other port number is used, it needs to be known by potential
Initiators. Initiators.
It is worth noting that UDP encapsulation of HIP packets reduces the
Maximum Transfer Unit (MTU) size of the control plane by 12 bytes.
5.2. Connectivity Checks 5.2. Connectivity Checks
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
5.3. Keepalives 5.3. Keepalives
The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
as specified in [RFC7401] with Notify message type field set to as specified in [RFC7401] with Notify message type field set to
NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification
skipping to change at page 40, line 27 skipping to change at page 40, line 30
Type 608 Type 608
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
UDP-ENCAPSULATION 1 UDP-ENCAPSULATION 1
ICE-STUN-UDP 2
ICE-HIP-UDP 3 ICE-HIP-UDP 3
Figure 8: 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.
Implementations conforming to this specification MUST implement UDP- Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes.
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 9 The TRANSACTION_PACING is defined in [RFC5770], but repeated in
contains only the connectivity check pacing value, expressed in Figure 9 for completeness. It contains only the connectivity check
milliseconds, as a 32-bit unsigned integer. pacing value, expressed in 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
skipping to change at page 44, line 23 skipping to change at page 45, line 17
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
Registration Type [RFC8003] values for Control Relay Server Registration Type [RFC8003] values for Control Relay Server
registration. The value for RELAY_UDP_HIP is 2 as specified in registration. The value for RELAY_UDP_HIP is 2 as specified in
Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD
by IANA: 3]). by IANA: 3]).
5.10. Notify Packet Types 5.10. Notify Packet Types
A Control/Data Relay Server and end-hosts can use NOTIFY packets to A Control/Data Relay Server and end-hosts can use NOTIFY packets to
signal different error conditions. The NOTIFY packet types are the signal different error conditions. The NOTIFY packet types are the
same as in Legacy ICE-HIP [RFC5770]. same as in Legacy ICE-HIP [RFC5770] except for last one, which is
new.
The Notify Packet Types [RFC7401] are shown below. The Notification The Notify Packet Types [RFC7401] are shown below. The Notification
Data field for the error notifications SHOULD contain the HIP header Data field for the error notifications SHOULD contain the HIP header
of the rejected packet and SHOULD be empty for the of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
skipping to change at page 45, line 31 skipping to change at page 46, line 28
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations (SAs) enable them to define a pair of IPsec ESP security associations (SAs)
as described in [RFC7402]. When two peers perform a UDP-encapsulated as described in [RFC7402]. When two peers perform a UDP-encapsulated
base exchange, they MUST define a pair of IPsec SAs that produces base exchange, they MUST define a pair of IPsec SAs that produces
UDP-encapsulated ESP data traffic. UDP-encapsulated ESP data traffic.
The management of encryption/authentication protocols and SPIs is The management of encryption/authentication protocols and SPIs is
defined in [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].
It is worth noting that UDP encapsulation of ESP reduces the MTU size
of data plane by 8 bytes.
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 12) 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 the RELAY_FROM and RELAY_TO parameters. This document specifies only the
use of UDP relaying, and, thus, only protocol 17 is allowed. use of UDP relaying, and, thus, only protocol 17 is allowed.
However, 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
skipping to change at page 47, line 30 skipping to change at page 48, line 30
| PAddress | | PAddress |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI | | OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4680] Type [TBD by IANA; 4680]
Length length in octets, excluding Type and Length Length 48
RPort the transport layer (UDP) port at the Data Relay Server RPort the transport layer (UDP) port at the Data Relay Server
(i.e. the port of the server reflexive candidate) (i.e. the port of the server reflexive candidate)
PPort the transport layer (UDP) port number of the peer PPort the transport layer (UDP) port number of the peer
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
RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the server reflexive candidate IPv6 address" format, of the server reflexive candidate
PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer IPv6 address" format, of the peer
skipping to change at page 51, line 28 skipping to change at page 52, line 28
gathering. Similarly to ICE TURN servers, Data Relay Server require gathering. Similarly to ICE TURN servers, Data Relay Server require
an authenticated base exchange that protects relayed address an authenticated base exchange that protects relayed address
gathering against fake requests and responses. Further, replay gathering against fake requests and responses. Further, replay
attacks are not possible because the HIP base exchange (and also attacks are not possible because the HIP base exchange (and also
UPDATE procedure) is protected against replay attacks. UPDATE procedure) is protected against replay attacks.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC8126]. This section is to be interpreted according to [RFC8126].
This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
plane and data plane traffic. The selection between Legacy ICE-HIP
and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE
parameter during the base exchange. By default, hosts listen this
port for incoming UDP datagrams and can use it also for sending UDP
datagrams. Other emphemeral port numbers are negotiated and utilized
dynamically.
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 (length 20), MAPPED_ADDRESS (length 20,
Section 5.12), and PEER_PERMISSION (defined in Section 5.13). defined in Section 5.12), PEER_PERMISSION (length 48, defined in
Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14)
and NOMINATE (length 4, defined in Section 5.15).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
traversal mode ICE-HIP-UDP (defined in Section 5.4) This traversal mode ICE-HIP-UDP (defined in Section 5.4).
specification introduces a new keepalive Notify message type field
NAT_KEEPALIVE. This document updates the IANA Registry for HIP Notify Message Types:
type field NAT_KEEPALIVE in Section 5.3 and a new error type
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.9.
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC8003] that allow registering with a Data Registration Extension [RFC8003] that allow registering with a Data
Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in
Section 4.1, and performing server reflexive candidate discovery: Section 5.9, and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2).
This document specifies new error values to be used in HIP NOTIFY
messages as described in Section 5.10:
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED,
MESSAGE_NOT_RELAYED and SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED.
ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral
Self-Address Fixing" . This protocol is based on ICE, and thus the Self-Address Fixing" . This protocol is based on ICE, and thus the
same considerations apply also here with one exception: this protocol same considerations apply also here with one exception: this protocol
does not hide binary IP addresses from application-level gateways. does not hide binary IP addresses from application-level gateways.
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 55, line 16 skipping to change at page 56, line 31
One way to estimate the RTT is to use the time that it takes for the One way to estimate the RTT is to use the time that it takes for the
Control Relay Server registration exchange to complete; this would Control Relay Server registration exchange to complete; this would
give an estimate on the registering host's access link's RTT. Also, give an estimate on the registering host's access link's RTT. Also,
the I1/R1 exchange could be used for estimating the RTT, but since the I1/R1 exchange could be used for estimating the RTT, but since
the R1 can be cached in the network, or the relaying service can the R1 can be cached in the network, or the relaying service can
increase the delay notably, this is not recommended. increase the delay notably, this is not recommended.
Appendix B. Differences with respect to ICE Appendix B. Differences with respect to ICE
Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The
benefits of such as an approach include the reuse of STUN/TURN
infrastructure and possibly the reuse of existing software libraries,
but there are also drawbacks with the approach. For example, ICE is
meant for application-layer protocols, whereas HIP operates at layer
3.5 between transport and network layers. This is particularly
problematic because the implementations employ IPsec ESP as their
data plane: demultiplexing of incoming ESP, HIP and TURN messages
required capturing of all UDP packets destined to port 10500 to the
userspace, thus causing additional software complexity and an
unnecessary latency/throughput bottleneck for the dataplane
performance. Also, relaying of ESP packets via TURN relays was not
considered that simple because TURN relays require adding and
removing extra TURN framing for the relayed packets. Finally, the
developers of the two Legacy ICE-HIP implementations concluded that
"effort needed for integrating an ICE library into a HIP
implementation turned out to be quite a bit higher that initially
estimated. Also, the amount of extra code (some 10 kLoC) needed for
all the new parsers, state machines, etc., is quite high and by re-
using the HIP code one should be able to do with much less. This
should result in smaller binary size, less bugs, and easier
debugging.". Consequently, the HIP working group decided to follow
ICE methodology but reuse HIP messaging format to achieve the same
functionality as ICE, and consequently the result is this document
that specifies the Native ICE-HIP protocol.
The Native ICE-HIP protocol specified in this document follows the The Native ICE-HIP protocol specified in this document follows the
semantics of ICE as close as possible, and most of the differences semantics of ICE as close as possible, and most of the differences
are syntactical due to the use of a different protocol. In this are syntactical due to the use of a different protocol. In this
section, we describe the differences to the ICE protocol. section, we describe the differences to the ICE protocol.
o ICE operates at the application layer, whereas this protocol o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o The STUN protocol is not employed. Instead, native ICE-HIP reuses o The STUN protocol is not employed. Instead, native ICE-HIP reuses
 End of changes. 29 change blocks. 
85 lines changed or deleted 129 lines changed or added

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