< draft-ietf-hip-nat-traversal-08.txt   draft-ietf-hip-nat-traversal-09.txt >
HIP Working Group M. Komu HIP Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Experimental T. Henderson Intended status: Experimental T. Henderson
Expires: December 31, 2009 The Boeing Company Expires: April 26, 2010 The Boeing Company
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
J. Melen J. Melen
A. Keranen, Ed. A. Keranen, Ed.
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
June 29, 2009 October 23, 2009
Basic HIP Extensions for Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-08.txt draft-ietf-hip-nat-traversal-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2009. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies extensions to the Host Identity Protocol This document specifies extensions to the Host Identity Protocol
(HIP) to facilitate Network Address Translator (NAT) traversal. The (HIP) to facilitate Network Address Translator (NAT) traversal. The
extensions are based on the use of the Interactive Connectivity extensions are based on the use of the Interactive Connectivity
Establishment (ICE) methodology to discover a working path between Establishment (ICE) methodology to discover a working path between
two end-hosts, and on standard techniques for encapsulating two end-hosts, and on standard techniques for encapsulating
Encapsulating Security Payload (ESP) packets within the User Datagram Encapsulating Security Payload (ESP) packets within the User Datagram
Protocol (UDP). This document also defines elements of procedure for Protocol (UDP). This document also defines elements of a procedure
NAT traversal, including the optional use of a HIP relay server. for NAT traversal, including the optional use of a HIP relay server.
With these extensions HIP is able to work in environments that have With these extensions HIP is able to work in environments that have
NATs and provides a generic NAT traversal solution to higher-layer NATs and provides a generic NAT traversal solution to higher-layer
networking applications. networking applications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 10, line 21 skipping to change at page 10, line 21
registration, the client sends NAT keepalives periodically to the registration, the client sends NAT keepalives periodically to the
relay to keep possible NAT bindings between the client and the relay relay to keep possible NAT bindings between the client and the relay
alive. The relay client maintains the HIP association with the relay alive. The relay client maintains the HIP association with the relay
server as long as it requires relaying service from it. server as long as it requires relaying service from it.
4.2. ICE Candidate Gathering 4.2. ICE Candidate Gathering
If a host is going to use ICE, it needs to gather a set of address If a host is going to use ICE, it needs to gather a set of address
candidates. The candidate gathering SHOULD be done as defined in candidates. The candidate gathering SHOULD be done as defined in
Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered
for only one media stream and component. Component ID 1 should be for the UDP encapsulated flow of HIP and ESP traffic. This flow
used for ICE processing, where needed. The Initiator takes the role corresponds to one ICE media stream and component. Since ICE
of the ICE controlling agent. component IDs are not needed, they are not explicitly signaled and ID
value of 1 SHOULD be used for ICE processing, where needed. The
Initiator takes the role of the ICE controlling agent.
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 is to be done before sending an I2 or R2 in the base exchange if ICE is to be
used for the connectivity checks. It is RECOMMENDED that all three used for the connectivity checks. It is RECOMMENDED that all three
types of candidates (host, server reflexive and relayed) are gathered types of candidates (host, server reflexive and relayed) are gathered
to maximize the probability of successful NAT traversal. However, if to maximize the probability of successful NAT traversal. However, if
no TURN server is used, and the host has only a single local IP no TURN server is used, and the host has only a single local IP
address to use, the host MAY use the local address as the only host address to use, the host MAY use the local address as the only host
candidate and the address from the REG_FROM parameter discovered candidate and the address from the REG_FROM parameter discovered
during the relay registration as a server reflexive candidate. In during the relay registration as a server reflexive candidate. In
skipping to change at page 12, line 29 skipping to change at page 12, line 29
retrying a previous check. If a host does not include this parameter retrying a previous check. If a host does not include this parameter
in the base exchange, a Ta value of 500ms MUST be used as that host's in the base exchange, a Ta value of 500ms MUST be used as that host's
minimum value. The value that is used by both of the hosts is the minimum value. 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.
Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta,
since such values may not work well with some NATs, as explained in since such values may not work well with some NATs, as explained in
[I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller
value than what the Responder offered. value than what the Responder offered.
The minimum Ta value SHOULD be configurable. Guidelines for The minimum Ta value SHOULD be configurable, and if no value is
selecting a Ta value are given in Appendix A. Currently this feature configured, value of 500ms MUST be used. Guidelines for selecting a
applies only to the ICE-STUN-UDP NAT traversal mode, but any other Ta value are given in Appendix A. Currently this feature applies
mode using connectivity checks SHOULD utilize this feature. only to the ICE-STUN-UDP NAT traversal mode, but any other mode using
connectivity checks SHOULD utilize this feature.
4.5. Base Exchange via HIP Relay Server 4.5. Base Exchange via HIP Relay Server
This section describes how Initiator and Responder perform a base This section describes how Initiator and Responder perform a base
exchange through a HIP relay server. The NAT traversal mode exchange through a HIP relay server. The NAT traversal mode
negotiation (denoted as NAT_TM in the example) was described in negotiation (denoted as NAT_TM in the example) was described in
Section 4.3 and is not repeated here. If a relay receives an R1 or Section 4.3 and is not repeated here. If a relay receives an R1 or
I2 packet without the NAT traversal mode parameter, it MUST drop it I2 packet without the NAT traversal mode parameter, it MUST drop it
and SHOULD send a NOTIFY error packet with type and SHOULD send a NOTIFY error packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2.
skipping to change at page 15, line 50 skipping to change at page 15, line 50
If the ICE connectivity checks failed, the hosts MUST NOT send ESP If the ICE connectivity checks failed, the hosts MUST NOT send ESP
traffic to each other but MAY continue communicating using HIP traffic to each other but MAY continue communicating using HIP
packets and the locators used for the base exchange. Also, the hosts packets and the locators used for the base exchange. Also, the hosts
SHOULD notify each other about the failure with a SHOULD notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
4.7. NAT Keepalives 4.7. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts send
periodically keepalives to each other. HIP relay servers MAY refrain periodic keepalives to each other. HIP relay servers MAY refrain
from sending keepalives if it's known that they are not behind a from sending keepalives if it's known that they are not behind a
middlebox that requires keepalives. An end-host MUST send keepalives middlebox that requires keepalives. An end-host MUST send keepalives
every 15 seconds to refresh the UDP port mapping at the NAT(s) when every 15 seconds to refresh the UDP port mapping at the NAT(s) when
the control or data channel is idle. To implement failure tolerance, the control or data channel is idle. To implement failure tolerance,
an end-host SHOULD have shorter keepalive period. an end-host SHOULD have shorter keepalive period.
The keepalives are STUN Binding Indications if the hosts have agreed The keepalives are STUN Binding Indications if the hosts have agreed
on ICE-STUN-UDP NAT traversal mode during the base exchange. on ICE-STUN-UDP NAT traversal mode during the base exchange.
Otherwise, HIP NOTIFY packets MAY be used as keepalives. Otherwise, HIP NOTIFY packets MAY be used as keepalives.
skipping to change at page 27, line 32 skipping to change at page 27, line 32
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.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
Upon publication of this document, IANA is requested to register a [TO BE REMOVED: Upon publication of this document, IANA is requested
UDP port and the RFC editor is requested to change all occurrences of to register a UDP port from the Registered Ports range and the RFC
port HIPPORT to the port IANA has registered. The HIPPORT number editor is requested to change all occurrences of port HIPPORT to the
50500 should be used for initial experimentation. port IANA has registered. The HIPPORT number 50500 should be used
for initial experimentation. ]
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type values for the new HIP [RFC5201] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in
Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING
(defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in
Section 5.4). Section 5.4).
This document defines an additional registration type for the HIP This document defines an additional registration type for the HIP
Registration Extension [RFC5203] that allows registering with a HIP Registration Extension [RFC5203] that allows registering with a HIP
relay server for relaying service: RELAY_UDP_HIP (defined in relay server for relaying service: RELAY_UDP_HIP (defined in
Section 5.9). Section 5.9).
This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER,
CONNECTIVITY_CHECKS_FAILED and MESSAGE_NOT_RELAYED Notify Packet CONNECTIVITY_CHECKS_FAILED and MESSAGE_NOT_RELAYED Notify Packet
Types [RFC5201] in Section 5.10. Types [RFC5201] in Section 5.10.
The NAT_TRAVERSAL_MODE parameter has 8-bit unsigned integer fields The NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields
for different modes, for which IANA is to create and maintain a new for different modes, for which IANA is to create and maintain a new
sub-registry entitled "HIP NAT traversal modes" under the "Host sub-registry entitled "HIP NAT traversal modes" under the "Host
Identity Protocol (HIP) Parameters". Initial values for the NAT Identity Protocol (HIP) Parameters". Initial values for the NAT
traversal mode registry are given in Section 5.4; future assignments traversal mode registry are given in Section 5.4; future assignments
are to be made through IETF Review [RFC5226]. Assignments consist of are to be made through IETF Review [RFC5226]. Assignments consist of
a NAT traversal mode identifier name and its associated value. [TO a NAT traversal mode identifier name and its associated value. [TO
BE REMOVED: This registration should take place at the following BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/hip-parameters/] location: http://www.iana.org/assignments/hip-parameters/]
8. Contributors 8. Contributors
skipping to change at page 28, line 46 skipping to change at page 28, line 47
Forces, Ericsson, and Birdstep. Forces, Ericsson, and Birdstep.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-15 (work in progress), June 2009. draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 31, line 43 skipping to change at page 31, line 43
| -00 | Initial version. | | -00 | Initial version. |
| -01 | Draft based on RVS. | | -01 | Draft based on RVS. |
| -02 | Draft based on Relay proxies and ICE concepts. | | -02 | Draft based on Relay proxies and ICE concepts. |
| -03 | Draft based on STUN/ICE formats. | | -03 | Draft based on STUN/ICE formats. |
| -04 | Issues 25-27,29-36 | | -04 | Issues 25-27,29-36 |
| -05 | Issues 28,40-43,47,49,51 | | -05 | Issues 28,40-43,47,49,51 |
| -06 | New copyright boilerplate and STUN username encoding | | -06 | New copyright boilerplate and STUN username encoding |
| -07 | New NOTIFY error packet parameters, changed handling | | -07 | New NOTIFY error packet parameters, changed handling |
| | of I2/R2 via relay with UDP-ENCAPSULATION mode | | | of I2/R2 via relay with UDP-ENCAPSULATION mode |
| -08 | Small editorial fixes regarding WGLC comments | | -08 | Small editorial fixes regarding WGLC comments |
| -09 | Small fixes regarding IESG and Gen-ART review comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
 End of changes. 12 change blocks. 
20 lines changed or deleted 25 lines changed or added

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