draft-ietf-hip-nat-traversal-05.txt   draft-ietf-hip-nat-traversal-06.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: May 4, 2009 The Boeing Company Expires: September 10, 2009 The Boeing Company
P. Matthews
(Unaffiliated)
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
J. Melen
A. Keranen, Ed. A. Keranen, Ed.
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
October 31, 2008 March 9, 2009
Basic HIP Extensions for Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-05.txt draft-ietf-hip-nat-traversal-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 May 4, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 procedure for
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8
4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12
4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 14 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 14
4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16
4.9. Simultaneous Base Exchange with and without UDP 4.9. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16
4.10. Sending Control Messages after the Base Exchange . . . . . 17 4.10. Sending Control Messages after the Base Exchange . . . . . 17
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 18 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 18
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20
5.6. Relay and Registration Parameters . . . . . . . . . . . . 21 5.6. Relay and Registration Parameters . . . . . . . . . . . . 21
5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 23 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 23
5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 23 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 23
5.10. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 24 5.10. Notify Message Types . . . . . . . . . . . . . . . . . . . 24
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 25 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 25
6.3. Base Exchange Replay Protection for HIP Relay Server . . . 25 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 25
6.4. Demuxing Different HIP Associations . . . . . . . . . . . 25 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28
Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 29 Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 29
Appendix C. Base Exchange through a Rendezvous Server . . . . . . 29 Appendix C. Base Exchange through a Rendezvous Server . . . . . . 29
Appendix D. Document Revision History . . . . . . . . . . . . . . 29 Appendix D. Document Revision History . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Introduction 1. Introduction
HIP [RFC5201] is defined as a protocol that runs directly over IPv4 HIP [RFC5201] is defined as a protocol that runs directly over IPv4
or IPv6, and HIP coordinates the setup of ESP security associations or IPv6, and HIP coordinates the setup of ESP security associations
[RFC5202] that are also specified to run over IPv4 or IPv6. This [RFC5202] that are also specified to run over IPv4 or IPv6. This
approach is known to have problems traversing NATs and other approach is known to have problems traversing NATs and other
middleboxes [RFC5207]. This document defines HIP extensions for the middleboxes [RFC5207]. This document defines HIP extensions for the
traversal of both Network Address Translator (NAT) and Network traversal of both Network Address Translator (NAT) and Network
Address and Port Translator (NAPT) middleboxes. The document Address and Port Translator (NAPT) middleboxes. The document
skipping to change at page 9, line 34 skipping to change at page 9, line 34
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
Figure 2: Example Registration to a HIP Relay Figure 2: Example Registration to a HIP Relay
In step 1, the relay client (Initiator) starts the registration In step 1, the relay client (Initiator) starts the registration
procedure by sending an I1 packet over UDP. It is RECOMMENDED that procedure by sending an I1 packet over UDP. It is RECOMMENDED that
the Initiator selects a random port number from the ephemeral port the Initiator selects a random port number from the ephemeral port
range 49152-65535 for initiating a base exchange. However, the range 49152-65535 for initiating a base exchange. Alternatively, a
allocated port MUST be maintained until all of the corresponding HIP host MAY also use a single fixed port for initiating all outgoing
Associations are closed. Alternatively, a host MAY also use a single connections. However, the allocated port MUST be maintained until
fixed port for initiating all outgoing connections. The HIP relay all of the corresponding HIP Associations are closed. It is
server MUST listen to incoming connections at UDP port HIPPORT. RECOMMENDED that the HIP relay server listens to incoming connections
at UDP port HIPPORT. If some other port number is used, it needs to
be communicated to possible Initiators.
In step 2, the HIP relay server (Responder) lists the services that In step 2, the HIP relay server (Responder) lists the services that
it supports in the R1 packet. The support for HIP-over-UDP relaying it supports in the R1 packet. The support for HIP-over-UDP relaying
is denoted by the RELAY_UDP_HIP value. is denoted by the Registration Type [RFC5203] value RELAY_UDP_HIP.
In step 3, the Initiator selects the services it registers for and In step 3, the Initiator selects the services it registers for and
lists them in the REG_REQ parameter. The Initiator registers for HIP lists them in the REG_REQ parameter. The Initiator registers for HIP
relay service by listing the RELAY_UDP_HIP value in the request relay service by listing the RELAY_UDP_HIP value in the request
parameter. parameter.
In step 4, the Responder concludes the registration procedure with an In step 4, the Responder concludes the registration procedure with an
R2 packet and acknowledges the registered services in the REG_RES R2 packet and acknowledges the registered services in the REG_RES
parameter. The Responder denotes unsuccessful registrations (if any) parameter. The Responder denotes unsuccessful registrations (if any)
in the REG_FAILED parameter of R2. The Responder also includes a in the REG_FAILED parameter of R2. The Responder also includes a
skipping to change at page 10, line 21 skipping to change at page 10, line 23
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 only one media stream and component. Component ID 1 should be
used for ICE processing, where needed. Initiator takes the role of used for ICE processing, where needed. Initiator takes the role of
the ICE controlling agent. 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 if ICE is used for the connectivity done before sending an I2 or R2 in the end-to-end base exchange (not
when registering to a relay) if ICE is used for the connectivity
checks. It is RECOMMENDED that all three types of candidates (host, checks. It is RECOMMENDED that all three types of candidates (host,
server reflexive and relayed) are gathered to maximize probability of server reflexive and relayed) are gathered to maximize the
successful NAT traversal. However, if no TURN server is used, and probability of successful NAT traversal. However, if no TURN server
the host has only a single local IP address to use, the host MAY use is used, and the host has only a single local IP address to use, the
the local address as the only host candidate and the address from the host MAY use the local address as the only host candidate and the
REG_FROM parameter discovered during the relay registration as a address from the REG_FROM parameter discovered during the relay
server reflexive candidate. In this case, no further candidate registration as a server reflexive candidate. In this case, no
gathering is needed. further candidate gathering is needed.
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, it can be ignored by an document. As the parameter is non-critical, it can be ignored by an
end-host which means that the host does not support or is not willing end-host which means that the host does not support or is not willing
to use these extensions. to use these extensions ("critical" parameters are defined in
[RFC5201]).
The NAT traversal mode parameter applies to a base exchange between The NAT traversal mode parameter applies to a base exchange between
end-hosts, but currently does not apply to a registration with a HIP end-hosts, but does not apply to a registration with a HIP relay
relay server. The NAT traversal mode negotiation in base exchange is server, which always uses UDP-ENCAPSULATION mode. The NAT traversal
illustrated in Figure 3. mode negotiation in a HIP base exchange is illustrated in Figure 3.
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+------------------------------------------------------------->| +------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<-------------------------------------------------------------+ |<-------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) |
+------------------------------------------------------------->| +------------------------------------------------------------->|
skipping to change at page 12, line 13 skipping to change at page 12, line 13
The locator parameter in R2 is the "ICE answer". The locator parameter in R2 is the "ICE answer".
4.4. Connectivity Check Pacing Negotiation 4.4. Connectivity Check Pacing Negotiation
As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with
connectivity checks is used, new transactions should not be started connectivity checks is used, new transactions should not be started
too fast to avoid congestion and overwhelming the NATs. too fast to avoid congestion and overwhelming the NATs.
For this purpose, during the base exchange, hosts can negotiate a For this purpose, during the base exchange, hosts can negotiate a
transaction pacing value, Ta, using a TRANSACTION_PACING parameter in transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
I2 and R2 messages. The parameter contains the minimum time R1 and I2 messages. The parameter contains the minimum time
(expressed in milliseconds) the host would wait between two NAT (expressed in milliseconds) the host would wait between two NAT
traversal transactions, such as starting a new connectivity check or traversal transactions, such as starting a new connectivity check or
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]. [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller
value than what the Responder offered.
The minimum Ta value SHOULD be configurable. Guidelines for The minimum Ta value SHOULD be configurable. Guidelines for
selecting a Ta value are given in Appendix A. Currently this feature selecting a Ta value are given in Appendix A. Currently this feature
applies only to the ICE-STUN-UDP NAT traversal mode. applies only to the ICE-STUN-UDP NAT traversal mode.
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 the negotiation (denoted as NAT_TM in the example) was described in the
previous section and shall not be repeated here. If a relay receives previous section and shall not be repeated here. If a relay receives
an R1 or I2 packet without the NAT traversal mode parameter, it drops an R1 or I2 packet without the NAT traversal mode parameter, it drops
it and sends a NOTIFY error message to the sender of the R1/I2. it and sends a NOTIFY error message with type
NO_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2.
It is RECOMMENDED that the Initiator sends an I1 packet encapsulated It is RECOMMENDED that the Initiator sends an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with an Respectively, the Responder MUST respond to such an I1 packet with a
R1 packet over the transport layer and using the same transport UDP encapsulated R1 packet and the rest of the base exchange, I2 and
protocol. The rest of the base exchange, I2 and R2, MUST also use R2, MUST also use UDP encapsulation.
the same transport protocol.
I HIP relay R I HIP relay R
| 1. UDP(I1) | | | 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) | +----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TM)) | | | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+ | 4. UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
skipping to change at page 13, line 30 skipping to change at page 13, line 30
| 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
Figure 4: Base Exchange via a HIP Relay Server Figure 4: Base Exchange via a HIP Relay Server
In step 1 of Figure 4, the Initiator sends an I1 packet over the In step 1 of Figure 4, the Initiator sends an I1 packet over the
transport layer to the HIT of the Responder (and IP address of the transport layer to the HIT of the Responder (and IP address of the
relay). The source address is one of the locators of the Initiator. relay). The source address is one of the locators of the Initiator.
In step 2, the HIP relay server receives the I1 packet at port In step 2, the HIP relay server receives the I1 packet. If the
HIPPORT. If the destination HIT belongs to a registered Responder, destination HIT belongs to a registered Responder, the relay
the relay processes the packet. Otherwise, the relay MUST drop the processes the packet. Otherwise, the relay MUST drop the packet
packet silently. The relay appends a RELAY_FROM parameter to the I1 silently. The relay appends a RELAY_FROM parameter to the I1 packet
packet which contains the transport source address and port of the I1 which contains the transport source address and port of the I1 as
as observed by the relay. The relay protects the I1 packet with observed by the relay. The relay protects the I1 packet with
RELAY_HMAC as described in [RFC5204], except that the parameter type RELAY_HMAC as described in [RFC5204], except that the parameter type
is different (see Section 5.8). The relay changes the source and is different (see Section 5.8). The relay changes the source and
destination ports and IP addresses of the packet to match the values destination ports and IP addresses of the packet to match the values
the Responder used when registering to the relay, i.e., the reverse the Responder used when registering to the relay, i.e., the reverse
of the R2 used in the registration. The relay MUST recalculate the of the R2 used in the registration. The relay MUST recalculate the
transport checksum and forward the packet to the Responder. transport checksum and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [RFC5201]. In addition, the processes it according to the rules in [RFC5201]. In addition, the
Responder validates the RELAY_HMAC according to [RFC5204] and Responder validates the RELAY_HMAC according to [RFC5204] and
skipping to change at page 14, line 35 skipping to change at page 14, line 35
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC5201]. It replies with an R2 packet and includes a according to [RFC5201]. It replies with an R2 packet and includes a
RELAY_TO parameter as explained in step 3. The R2 packet includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a
LOCATOR parameter that lists all the ICE candidates (ICE answer) of LOCATOR parameter that lists all the ICE candidates (ICE answer) of
the Responder. The RELAY_TO parameter is protected by the HMAC. the Responder. The RELAY_TO parameter is protected by the HMAC.
In step 8, the relay processes the R2 as described in step 4. The In step 8, the relay processes the R2 as described in step 4. The
relay forwards the packet to the Initiator. relay forwards the packet to the Initiator.
Hosts MAY include the address of their HIP relay server in the Hosts MUST include the address of one or more HIP relay servers
LOCATOR parameter in I2/R2. The traffic type of this address MUST be (including the one that is being used for the initial signaling) in
"HIP signaling" and it MUST NOT be used as an ICE candidate. This the LOCATOR parameter in I2/R2 if they intend to use such servers for
address MAY be used for HIP signaling also after the base exchange. relaying HIP signaling after the base exchange completes. The
If the HIP relay server locator is not included in I2/R2 LOCATOR traffic type of these addresses MUST be "HIP signaling" and they MUST
parameters, it SHOULD NOT be used after the base exchange, but the NOT be used as ICE candidates. If the HIP relay server locator used
HIP signaling SHOULD use the same path as the data traffic. for the base exchange is not included in I2/R2 LOCATOR parameters, it
SHOULD NOT be used after the base exchange, but further HIP signaling
SHOULD use the same path as the data traffic.
4.6. ICE Connectivity Checks 4.6. ICE Connectivity Checks
If a HIP relay server was used, the Responder completes the base If a HIP relay server was used, the Responder completes the base
exchange with the R2 packet through the relay. When the Initiator exchange with the R2 packet through the relay. However, the
successfully receives and processes the R2, both hosts have destination address the Initiator and Responder used for delivering
transitioned to ESTABLISHED state. However, the destination address base exchange packets belonged to the HIP relay server. Therefore,
the Initiator and Responder used for delivering base exchange packets the address of the relay MUST NOT be used for sending ESP traffic.
belonged to the HIP relay server. Therefore, the address of the
relay MUST NOT be used for sending ESP traffic. Instead, if a NAT Instead, if a NAT traversal mode with ICE connectivity checks was
traversal mode with ICE connectivity checks was selected, the selected, the Initiator and Responder MUST start the connectivity
Initiator and Responder MUST start the connectivity checks. checks.
Creating the check list for the ICE connectivity checks should be Creating the check list for the ICE connectivity checks should be
performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] performed as described in Section 5.7 of [I-D.ietf-mmusic-ice]
bearing in mind that only one media stream and component is needed bearing in mind that only one media stream and component is needed
(so there will be only a single checklist and all candidates should (so there will be only a single checklist and all candidates should
have the same component ID value). The actual connectivity checks have the same component ID value). The actual connectivity checks
MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice]. MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice].
Regular mode SHOULD be used for the candidate nomination. Regular mode SHOULD be used for the candidate nomination.
Section 5.2 defines the details of the STUN control packets. As a Section 5.2 defines the details of the STUN control packets. As a
result of the ICE connectivity checks, ICE nominates a single result of the ICE connectivity checks, ICE nominates a single
skipping to change at page 16, line 13 skipping to change at page 16, line 14
NOTIFY message to the relay to keep the NAT states alive on the path NOTIFY message to the relay to keep the NAT states alive on the path
between the Initiator and relay when the Initiator has not received between the Initiator and relay when the Initiator has not received
any response to its I1 or I2 from the Responder in 15 seconds. The any response to its I1 or I2 from the Responder in 15 seconds. The
relay MUST NOT forward the NOTIFY messages. relay MUST NOT forward the NOTIFY messages.
4.8. Base Exchange without ICE Connectivity Checks 4.8. Base Exchange without ICE Connectivity Checks
In certain network environments, the ICE connectivity checks can be In certain network environments, the ICE connectivity checks can be
omitted to reduce initial connection set up latency because base omitted to reduce initial connection set up latency because base
exchange acts as an implicit connectivity test itself. There are exchange acts as an implicit connectivity test itself. There are
three assumptions about such as environments. First, the Responder three assumptions about such environments. First, the Responder
should have a long-term, fixed locator in the network. Second, the should have a long-term, fixed locator in the network. Second, the
Responder should not have a HIP relay server configured for itself. Responder should not have a HIP relay server configured for itself.
Third, the Initiator can reach the Responder by simply UDP Third, the Initiator can reach the Responder by simply UDP
encapsulating HIP and ESP packets to the host. Detecting and encapsulating HIP and ESP packets to the host. Detecting and
configuring this particular scenario is prone to administrative configuring this particular scenario is prone to failure unless
failure unless carefully planned. carefully planned.
In such a scenario, the Responder MAY include only the UDP- In such a scenario, the Responder MAY include only the UDP-
ENCAPSULATION NAT traversal mode in the R1 message. Likewise, if the ENCAPSULATION NAT traversal mode in the R1 message. Likewise, if the
Initiator knows that it can receive ESP and HIP signaling traffic by Initiator knows that it can receive ESP and HIP signaling traffic by
using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION
mode in the I2 message, if the Responder listed it in the supported mode in the I2 message, if the Responder listed it in the supported
modes. In both of these cases the locators from I2 and R2 packets modes. In both of these cases the locators from I2 and R2 packets
will be used also for the UDP encapsulated ESP. will be used also for the UDP encapsulated ESP.
When no ICE connectivity checks are used, locator exchange and return When no ICE connectivity checks are used, locator exchange and return
routability tests for mobility and multihoming are done as specified routability tests for mobility and multihoming are done as specified
in [RFC5206] with the exception that UDP encapsulation is used. in [RFC5206] with the exception that UDP encapsulation is used.
4.9. Simultaneous Base Exchange with and without UDP Encapsulation 4.9. Initiating a Base Exchange both with and without UDP Encapsulation
The Initiator MAY also try to simultaneously perform a base exchange The Initiator MAY also try to simultaneously perform a base exchange
with the Responder without UDP encapsulation. In such a case, the with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while encapsulation, to the Responder. The Initiator MAY wait for a while
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly at the The I1 packet without UDP encapsulation may arrive directly at the
skipping to change at page 18, line 45 skipping to change at page 18, line 45
A HIP relay server or a Responder without a relay MUST listen at UDP A HIP relay server or a Responder without a relay MUST listen at UDP
port HIPPORT for incoming UDP encapsulated HIP control packets. port HIPPORT for incoming UDP encapsulated HIP control packets.
5.2. Connectivity Checks 5.2. Connectivity Checks
The connectivity checks are performed using STUN Binding Requests as The connectivity checks are performed using STUN Binding Requests as
defined in [I-D.ietf-mmusic-ice]. This section describes the details defined in [I-D.ietf-mmusic-ice]. This section describes the details
of the parameters in the STUN messages. of the parameters in the STUN messages.
The Binding Requests MUST use STUN short term credentials with HITs The Binding Requests MUST use STUN short term credentials with last
of the Initiator and Responder as the username fragments. The 32 bits of the HITs of the Initiator and Responder as the username
username is formed from the username fragments as defined in Section fragments. The username is formed from the username fragments as
7.1.1.3 of [I-D.ietf-mmusic-ice] with the Initiator being the defined in Section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The 32 bit
"offerer" and the Responder being the "answerer". The HITs are used username fragments are expressed using lowercase hexadecimal ASCII
as usernames by expressing them in IPv6 hexadecimal ASCII format characters. The leading zeroes MUST NOT be omitted so that the
[RFC1884], using lowercase letters, each 16 bit HIT fragment username's size is fixed (8 characters): for example, if the local
separated by a one byte colon (hex 0x3a). The leading zeroes MUST HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is
NOT be omitted so that the username's size is fixed. 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be
72376c0a and the remote username 0051047b.
The STUN password is drawn from the DH keying material. Drawing of The STUN password is drawn from the DH keying material. Drawing of
HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys HIP keys is defined in [RFC5201] Section 6.5 and drawing of ESP keys
in [RFC5202] Section 7. Correspondingly, the hosts MUST draw in [RFC5202] Section 7. Correspondingly, the hosts MUST draw
symmetric keys for STUN according to [RFC5201] Section 6.5. The symmetric keys for STUN according to [RFC5201] Section 6.5. The
hosts draw the STUN key after HIP keys, or after ESP keys if ESP hosts draw the STUN key after HIP keys, or after ESP keys if ESP
transform was successfully negotiated in the base exchange. Both transform was successfully negotiated in the base exchange. Both
hosts draw a 128 bit key from the DH keying material, express that in hosts draw a 128 bit key from the DH keying material, express that in
hexadecimal ASCII format using only lowercase letters (resulting in hexadecimal ASCII format using only lowercase letters (resulting in
32 numbers or lowercase letters), and use that as both the local and 32 numbers or lowercase letters), and use that as both the local and
skipping to change at page 23, line 36 skipping to change at page 23, line 36
| Transport | Variable | IANA Assigned, transport layer Internet | | Transport | Variable | IANA Assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. | | | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-mmusic-ice] | | | | [I-D.ietf-mmusic-ice] |
| SPI | Variable | SPI value which the host expects to see in | | SPI | Variable | SPI value which the host expects to see in |
| | | incoming ESP packets that use this locator | | | | incoming ESP packets that use this locator |
| Locator | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Locator | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC3513] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR parameter Table 2: Fields of the LOCATOR parameter
5.8. RELAY_HMAC Parameter 5.8. RELAY_HMAC Parameter
The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
2^4). It has the same semantics as RVS_HMAC [RFC5204]. 2^4). It has the same semantics as RVS_HMAC [RFC5204].
5.9. Registration Types 5.9. Registration Types
The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain
values for HIP relay server registration. The value for Registration Type [RFC5203] values for HIP relay server registration.
RELAY_UDP_HIP is 2. The value for RELAY_UDP_HIP is 2.
5.10. ESP Data Packets 5.10. Notify Message Types
If the HIP relay server does not forward a base exchange message due
to missing NAT traversal mode parameter, it sends back a NOTIFY error
message with Notify Message Type [RFC5201]
NO_NAT_TRAVERSAL_MODE_PARAMETER. The value for this type is 60. The
Notification Data field for the error message MUST be empty.
5.11. ESP Data Packets
[RFC3948] describes UDP encapsulation of the IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. On the wire, the HIP ESP packets do not differ from the tunnel mode. On the wire, the HIP ESP packets do not differ from the
transport mode ESP and thus the encapsulation of the HIP ESP packets transport mode ESP and thus the encapsulation of the HIP ESP packets
is same as the UDP encapsulation transport mode ESP. However, the is same as the UDP encapsulation transport mode ESP. However, the
(semantic) difference to BEET mode ESP packets used by HIP is that IP (semantic) difference to BEET mode ESP packets used by HIP is that IP
header is not used in BEET integrity protection calculation. header is not used in BEET integrity protection calculation.
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations (SAs) enable them to define a pair of IPsec ESP security associations (SAs)
skipping to change at page 25, line 46 skipping to change at page 26, line 7
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder uses HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC5226].
This draft currently uses a UDP port in the "Dynamic and/or Private This draft currently uses a UDP port in the "Dynamic and/or Private
Port" and HIPPORT. Upon publication of this document, IANA is Port" and HIPPORT. Upon publication of this document, IANA is
requested to register a UDP port and the RFC editor is requested to requested to register a UDP port and the RFC editor is requested to
change all occurrences of port HIPPORT to the port IANA has change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial registered. The HIPPORT number 50500 should be used for initial
experimentation. experimentation.
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA Registry for HIP Parameter Types
assigning new HIP Parameter Type values for the new HIP Parameters: [RFC5201] by assigning new HIP Parameter Type values for the new HIP
RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.6), Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in
RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING (defined in Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING
Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4). (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in
Section 5.4).
This document defines an additional registration type for the HIP
Registration Extension [RFC5203] that allows registering with a HIP
relay server for relaying service: RELAY_UDP_HIP (defined in
Section 5.9).
This document also defines a NO_NAT_TRAVERSAL_MODE_PARAMETER Notify
Message Type [RFC5201] in Section 5.10.
8. Contributors 8. Contributors
This draft is a product of a design team which also included Marcelo This draft is a product of a design team which also included Marcelo
Bagnulo and Jan Melen who both have made major contributions to this Bagnulo and Philip Matthews who both have made major contributions to
document. this document.
9. Acknowledgments 9. Acknowledgments
Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for
the excellent work on ICE. In addition, the authors would like to the excellent work on ICE. In addition, the authors would like to
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Vivien Schmitt, Abhinav Pathak for their contributions and Tobias Vivien Schmitt, Abhinav Pathak for their contributions and Tobias
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian
Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka
Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and
skipping to change at page 26, line 44 skipping to change at page 27, line 14
Forces, and Ericsson and Birdstep. Forces, and 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-11 (work in progress), draft-ietf-behave-turn-13 (work in progress),
October 2008. February 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.
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Architecture", RFC 4291, February 2006.
October 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
skipping to change at page 27, line 42 skipping to change at page 27, line 50
Protocol (HIP) Registration Extension", RFC 5203, Protocol (HIP) Registration Extension", RFC 5203,
April 2008. April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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,
October 2008. October 2008.
10.2. Informative References 10.2. Informative References
[I-D.heer-hip-middle-auth] [I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-01 (work in progress), draft-heer-hip-middle-auth-01 (work in progress),
skipping to change at page 30, line 14 skipping to change at page 30, line 22
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| draft-ietf-nat-traversal-00 | Initial version. | | draft-ietf-nat-traversal-00 | Initial version. |
| draft-ietf-nat-traversal-01 | Draft based on RVS. | | draft-ietf-nat-traversal-01 | Draft based on RVS. |
| draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and |
| | ICE concepts. | | | ICE concepts. |
| draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. |
| draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | | draft-ietf-nat-traversal-04 | Issues 25-27,29-36 |
| draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 | | draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 |
| draft-ietf-nat-traversal-06 | New copyright boilerplate and STUN |
| | username encoding |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
skipping to change at page 30, line 36 skipping to change at page 31, line 4
Email: miika@iki.fi Email: miika@iki.fi
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Thomas Henderson Thomas Henderson
The Boeing Company The Boeing Company
P.O. Box 3707 P.O. Box 3707
Seattle, WA Seattle, WA
USA USA
Email: thomas.r.henderson@boeing.com Email: thomas.r.henderson@boeing.com
Philip Matthews
(Unaffiliated)
Email: philip_matthews@magma.ca
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Ari Keranen (editor) Jan Melen
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Phone: +358 9 2991 Phone: +358 9 2991
Email: ari.keranen@ericsson.com Email: jan.melen@ericsson.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Ari Keranen (editor)
assurances of licenses to be made available, or the result of an Ericsson Research Nomadiclab
attempt made to obtain a general license or permission for the use of Hirsalantie 11
such proprietary rights by implementers or users of this 02420 Jorvas
specification can be obtained from the IETF on-line IPR repository at Finland
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Phone: +358 9 2991
copyrights, patents or patent applications, or other proprietary Email: ari.keranen@ericsson.com
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 45 change blocks. 
140 lines changed or deleted 151 lines changed or added

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