draft-ietf-hip-native-nat-traversal-20.txt   draft-ietf-hip-native-nat-traversal-21.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: October 27, 2017 Ericsson Expires: April 26, 2018 Ericsson
April 25, 2017 October 23, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-20 draft-ietf-hip-native-nat-traversal-21
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 October 27, 2017. This Internet-Draft will expire on April 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 12 4.2. Transport Address Candidate Gathering at the Relay Client 12
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 14 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 16 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 16
4.5. Base Exchange via Control Relay Server . . . . . . . . . 16 4.5. Base Exchange via Control Relay Server . . . . . . . . . 16
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 20 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 20
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 23 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 23
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 25 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 25
4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 26 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 26
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 26 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 26
4.7.2. Base Exchange without Connectivity Checks . . . . . . 26 4.7.2. Base Exchange without Connectivity Checks . . . . . . 26
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
skipping to change at page 3, line 21 skipping to change at page 3, line 21
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 47 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Normative References . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . 50 10.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 51 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 51
Appendix B. Differences with respect to ICE . . . . . . . . . . 52 Appendix B. Differences with respect to ICE . . . . . . . . . . 52
Appendix C. Differences to Base Exchange and UPDATE procedures . 53 Appendix C. Differences to Base Exchange and UPDATE procedures . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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.
As one solution, the HIP experiment report [RFC6538] mentions that As one solution, the HIP experiment report [RFC6538] mentions that
Teredo based NAT traversal for HIP and related ESP traffic (with Teredo based NAT traversal for HIP and related ESP traffic (with
double tunneling overhead). Another solution is specified in double tunneling overhead). Another solution is specified in
[RFC5770], which will be referred as "Legacy ICE-HIP" in this [RFC5770], which will be referred as "Legacy ICE-HIP" in this
document. The experimental Legacy ICE-HIP specification combines document. The experimental Legacy ICE-HIP specification combines
Interactive Connectivity Establishment (ICE) protocol Interactive Connectivity Establishment (ICE) protocol
[I-D.ietf-ice-rfc5245bis] with HIP, so that basically ICE is [I-D.ietf-ice-rfc5245bis] with HIP, so that basically ICE is
responsible of NAT penetration and connectivity testing, while HIP is responsible of NAT traversal and connectivity testing, while HIP is
responsible of end-host authentication and IPsec key management. The responsible of end-host authentication and IPsec key management. The
resulting protocol uses HIP, STUN and ESP messages tunneled over a resulting protocol uses HIP, STUN and ESP messages tunneled over a
single UDP flow. The benefit of using ICE and its STUN/TURN single UDP flow. The benefit of using ICE and its STUN/TURN
messaging formats is that one can re-use the NAT traversal messaging formats is that one can re-use the NAT traversal
infrastructure already available in the Internet, such as STUN and infrastructure already available in the Internet, such as STUN and
TURN servers. Also, some middleboxes may be STUN-aware and may be TURN servers. Also, some middleboxes may be STUN-aware and may be
able to do something "smart" when they see STUN being used for NAT able to do something "smart" when they see STUN being used for NAT
traversal. traversal.
Implementing a full ICE/STUN/TURN protocol stack as specified in Implementing a full ICE/STUN/TURN protocol stack as specified in
skipping to change at page 4, line 37 skipping to change at page 4, line 37
can deliver ESP protected application payload to each other. When can deliver ESP protected application payload to each other. When
either of the hosts moves and changes its IP address, the two hosts either of the hosts moves and changes its IP address, the two hosts
re-establish connectivity using the mobility extensions [RFC8046]. re-establish connectivity using the mobility extensions [RFC8046].
The reader is also recommended to get familiar with the mobility The reader is also recommended to get familiar with the mobility
extensions, but basically it is a three-way procedure, where the extensions, but basically it is a three-way procedure, where the
mobile host first announces its new location to the peer, and then mobile host first announces its new location to the peer, and then
the peer tests for connectivity (so called return routability check), the peer tests for connectivity (so called return routability check),
for which the mobile hosts must respond in order to activate its new for which the mobile hosts must respond in order to activate its new
location. This specification builds on the mobility procedures, but location. This specification builds on the mobility procedures, but
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. mobility extensions specified in Appendix C. It is worth noting that
multihoming support as specified in [RFC8078] is left for further
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.
2. Terminology 2. Terminology
skipping to change at page 8, line 34 skipping to change at page 8, line 34
+-------+ +-------+ +-------+ +-------+
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 penetration 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 for
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 it is the Initiator may also have registered
to a Control and/or Data Relay Server. It is worth noting that a to a Control and/or Data Relay Server. It is worth noting that a
Control and Data Relay does not forge the source address of a passing Control and Data Relay does not forge the source address of a passing
packet, but always translates the source address and source port of a packet, but always translates the source address and source port of a
packet to be forwarded (to its own). packet 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(es) (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 (or other infrastructure including STUN or TURN
servers) for gathering the candidates. Next, the HIP base exchange servers) for gathering the candidates. Next, the HIP base exchange
is carried out by encapsulating the HIP control packets in UDP is carried out by encapsulating the HIP control packets in 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
skipping to change at page 12, line 11 skipping to change at page 12, line 11
parameter. The Relay Server denotes unsuccessful registrations (if parameter. The Relay Server denotes unsuccessful registrations (if
any) in the REG_FAILED parameter of R2. The Relay Server also any) in the REG_FAILED parameter of R2. The Relay Server also
includes a REG_FROM parameter that contains the transport address of includes a REG_FROM parameter that contains the transport address of
the Relay Client as observed by the Relay Server (Server Reflexive the Relay Client as observed by the Relay Server (Server Reflexive
candidate). If the Relay Client registered to ESP relaying service, candidate). If the Relay Client registered to ESP relaying service,
the Relay Server includes RELAYED_ADDRESS parameter that describes the Relay Server includes RELAYED_ADDRESS parameter that describes
the UDP port allocated to the Relay Client for ESP relaying. It is the UDP port allocated to the Relay Client for ESP relaying. It is
worth noting that the Data Relay Client must first activate this UDP worth noting that the Data Relay Client must first activate this UDP
port by sending an UPDATE message to the Data Relay Server that port by sending an UPDATE message to the Data Relay Server that
includes a PEER_PERMISSION parameter as described in Section 4.12.1 includes a PEER_PERMISSION parameter as described in Section 4.12.1
both after base exchange and handover procedures. both after base exchange and handover procedures. Also, the Data
Relay Server should follow the port allocation recommendations in
Section 6.5.
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 Relay Client and the relay alive. The keepalive between the Relay Client and the relay alive. The keepalive
extensions are described in Section 4.10. extensions are described in Section 4.10.
The Data Relay Client MUST maintain an active HIP association with The Data Relay Client MUST maintain an active HIP association with
the Data Relay Server as long as it requires the data relaying the Data Relay Server as long as it requires the data relaying
service. When the HIP association is closed (or times out), or the service. When the HIP association is closed (or times out), or the
registration lifetime passes without the Data Relay Client refreshing registration lifetime passes without the Data Relay Client refreshing
skipping to change at page 12, line 48 skipping to change at page 12, line 50
Client to learn its new server reflexive address candidate. Client to learn its new server reflexive address candidate.
4.2. Transport Address Candidate Gathering at the Relay Client 4.2. Transport Address Candidate Gathering at the Relay Client
An Initiator needs to gather a set of address candidates before An Initiator needs to gather a set of address candidates before
contacting a (non-relay) Responder. The candidates are needed for contacting a (non-relay) Responder. The candidates are needed for
connectivity checks that allow two hosts to discover a direct, non- connectivity checks that allow two hosts to discover a direct, non-
relayed path for communicating with each other. One server reflexive relayed path for communicating with each other. One server reflexive
candidate can be discovered during the registration with the Control candidate can be discovered during the registration with the Control
Relay Server from the REG_FROM parameter (and another from Data Relay Relay Server from the REG_FROM parameter (and another from Data Relay
Server if one is employed). It should be noted discovering multiple Server if one is employed).
address candidates in a multihoming configuration are left for
further study.
The candidate gathering can be done at any time, but it needs to be The candidate gathering can be done at any time, but it needs to be
done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP
mode is to be used for the connectivity checks. It is RECOMMENDED mode is to be used for the connectivity checks. It is RECOMMENDED
that all three types of candidates (host, server reflexive, and that all three types of candidates (host, server reflexive, and
relayed) are gathered to maximize the probability of successful NAT relayed) are gathered to maximize the probability of successful NAT
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.
If a Relay Client has more than one network interface, it can
discover additional server reflexive candidates by sending UPDATE
messages from each of its interfaces to the Relay Server. Each such
UPDATE message MUST include the following parameters: registration
request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGN
parameter. When a Control Relay Server receives an UPDATE message
with registration request containing a CANDIDATE_DISCOVERY type, it
MUST include a REG_FROM parameter, containing the same information as
if this were a Control Relay Server registration, to the response (in
addition to the mandatory ECHO_RESPONSE_SIGNED paramater). This
request type SHOULD NOT create any state at the Control Relay Server.
ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are
followed here. A number of host candidates (loopback, anycast and followed here. A number of host candidates (loopback, anycast and
others) should be excluded as described in the ICE specification others) should be excluded as described in the ICE specification
[I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in
order to guarantee successful NAT traversal, and implementations order to guarantee successful NAT traversal, and implementations
SHOULD support this functionality even if it will not be used in SHOULD support this functionality even if it will not be used in
deployments in order to enable it by software configuration update if deployments in order to enable it by software configuration update if
needed at some point. A host SHOULD employ only a single server for needed at some point. A host SHOULD employ only a single server for
gathering the candidates for a single HIP association; either a one gathering the candidates for a single HIP association; either a one
server providing both Control and Data Relay Server functionality, or server providing both Control and Data Relay Server functionality, or
skipping to change at page 35, line 13 skipping to change at page 35, line 13
delivers a new relayed address candidate upon SPI collisions. Each delivers a new relayed address candidate upon SPI collisions. Each
relayed address has a separate UDP port reserved to it, so collision relayed address has a separate UDP port reserved to it, so collision
problem does not occur. problem does not occur.
In the second scenario, the SPI collision problems occurs if two In the second scenario, the SPI collision problems occurs if two
hosts have registered to the same Data Relay Server and a third host hosts have registered to the same Data Relay Server and a third host
initiates base exchange with both of them. Here, the two Responders initiates base exchange with both of them. Here, the two Responders
(i.e. Data Relay Clients) claim the same inbound SPI number with the (i.e. Data Relay Clients) claim the same inbound SPI number with the
same Initiator (peer). However, in this case, the Data Relay Server same Initiator (peer). However, in this case, the Data Relay Server
has allocated separate UDP ports for the two Data Relay Clients has allocated separate UDP ports for the two Data Relay Clients
acting now as Responders. When the peer sends an ESP packet, the acting now as Responders (as recommended in Section 6.5). When the
Data Relay Server is able to forward the packet to the correct Data peer sends an ESP packet, the Data Relay Server is able to forward
Relay Client because the destination UDP port for each of the the packet to the correct Data Relay Client because the destination
clients. UDP port for each of the clients.
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 the sake It is worth noting that most of the parameters are shown for the sake
of completeness even though they are specified already in Legacy ICE- of completeness even though they are specified already in Legacy ICE-
HIP [RFC5770]. New parameters are explicitly described as new. HIP [RFC5770]. New parameters are explicitly described as new.
skipping to change at page 48, line 38 skipping to change at page 48, line 38
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) This
specification introduces a new keepalive Notify message type field specification introduces a new keepalive Notify message type field
NAT_KEEPALIVE. NAT_KEEPALIVE.
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. Section 4.1, and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2).
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
skipping to change at page 49, line 44 skipping to change at page 49, line 44
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003, Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>. October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <http://www.rfc-editor.org/info/rfc8004>. October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046, with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc8046>. editor.org/info/rfc8046>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017, <https://www.rfc-
editor.org/info/rfc8078>.
[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,
skipping to change at page 54, line 11 skipping to change at page 54, line 13
Section 4.7.2, thus merely tunneling HIP control and data traffic Section 4.7.2, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address. cases where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has o It is worth noting that while a rendezvous server [RFC8004] has
not been designed to be used in NATted scenarios because it just not been designed to be used in NATted scenarios because it just
relays the first I1 packet and does not employ UDP encapsulation, relays the first I1 packet and does not employ UDP encapsulation,
the Control Relay Server forwards all control traffic and, hence, the Control Relay Server forwards all control traffic and, hence,
is more suitable in NATted environments. Further, the Data Relay is more suitable in NATted environments. Further, the Data Relay
Server guarantees forwarding of data plane traffic also in the Server guarantees forwarding of data plane traffic also in the
cases when the NAT penetration procedures fail. cases when the NAT traversal procedures fail.
o Registration procedures with a Control/Data Relay Server are o Registration procedures with a Control/Data Relay Server are
similar as with rendezvous server. However, a Control/Data Relay similar as with rendezvous server. However, a Control/Data Relay
Server has different registration parameters than rendezvous Server has different registration parameters than rendezvous
because it offers a different service. Also, the Control/Data because it offers a different service. Also, the Control/Data
Relay Server includes also a REG_FROM parameter that informs the Relay Server includes also a REG_FROM parameter that informs the
Control/Data Relay Client about its server reflexive address. A Control/Data Relay Client about its server reflexive address. A
Data Relay Server includes also a RELAYED_ADDRESS containing the Data Relay Server includes also a RELAYED_ADDRESS containing the
relayed address for the Data Relay Client. relayed address for the Data Relay Client.
skipping to change at page 55, line 13 skipping to change at page 55, line 16
different in the sense that they merely acknowledge and conclude different in the sense that they merely acknowledge and conclude
the reception of the candidates through the Control Relay Server. the reception of the candidates through the Control Relay Server.
In other words, they do not yet test for connectivity (besides In other words, they do not yet test for connectivity (besides
reachability through the Control Relay Server) unlike in the reachability through the Control Relay Server) unlike in the
mobility extensions. The idea is that connectivity check mobility extensions. The idea is that connectivity check
procedure follows the ICE specification, which is somewhat procedure follows the ICE specification, which is somewhat
different from the HIP mobility extensions. different from the HIP mobility extensions.
o The connectivity checks as defined in the mobility extensions o The connectivity checks as defined in the mobility extensions
[RFC8046] are triggered only by the peer of the mobile host. [RFC8046] are triggered only by the peer of the mobile host.
Since successful NAT penetration requires that both end-points Since successful NAT traversal requires that both end-points test
test connectivity, both the mobile host and its peer host have to connectivity, both the mobile host and its peer host have to test
test for connectivity. In addition, this protocol validates also for connectivity. In addition, this protocol validates also the
the UDP ports; the ports in the connectivity check must match with UDP ports; the ports in the connectivity check must match with the
the response, as required by ICE. response, as required by ICE.
o In HIP mobility extensions [RFC8046], an outbound locator has some o In HIP mobility extensions [RFC8046], an outbound locator has some
associated state: UNVERIFIED mean that the locator has not been associated state: UNVERIFIED mean that the locator has not been
tested for reachability, ACTIVE means that the address has been tested for reachability, ACTIVE means that the address has been
verified for reachability and is being used actively, and verified for reachability and is being used actively, and
DEPRECATED means that the locator lifetime has expired. In the DEPRECATED means that the locator lifetime has expired. In the
subset of ICE specifications used by this protocol, an individual subset of ICE specifications used by this protocol, an individual
address candidate has only two properties: type and priority. address candidate has only two properties: type and priority.
Instead, the actual state in ICE is associated with candidate Instead, the actual state in ICE is associated with candidate
pairs rather than individual addresses. The subset of ICE pairs rather than individual addresses. The subset of ICE
 End of changes. 17 change blocks. 
27 lines changed or deleted 48 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/