draft-ietf-hip-nat-traversal-07.txt   draft-ietf-hip-nat-traversal-08.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 11, 2009 The Boeing Company Expires: December 31, 2009 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 9, 2009 June 29, 2009
Basic HIP Extensions for Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-07.txt draft-ietf-hip-nat-traversal-08.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 11, 2009. This Internet-Draft will expire on December 31, 2009.
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
skipping to change at page 9, line 29 skipping to change at page 9, line 29
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
| | | |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 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 with 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. Alternatively, a range 49152-65535 for initiating a base exchange. Alternatively, a
host MAY also use a single fixed port for initiating all outgoing host MAY also use a single fixed port for initiating all outgoing
connections. However, the allocated port MUST be maintained until connections. However, the allocated port MUST be maintained until
all of the corresponding HIP Associations are closed. It is all of the corresponding HIP Associations are closed. It is
RECOMMENDED that the HIP relay server listens to incoming connections RECOMMENDED that the HIP relay server listens to incoming connections
at UDP port HIPPORT. If some other port number is used, it needs to at UDP port HIPPORT. If some other port number is used, it needs to
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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
REG_FROM parameter that contains the transport address of the client REG_FROM parameter that contains the transport address of the client
as observed by the relay (Server Reflexive candidate). After the as observed by the relay (Server Reflexive candidate). After the
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. alive. The relay client maintains the HIP association with the relay
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 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. The Initiator takes the role
the ICE controlling agent. 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 10, line 45 skipping to change at page 10, line 46
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical (as defined in Section document. As the parameter is non-critical (as defined in Section
5.2.1 of [RFC5201]), it can be ignored by an end-host which means 5.2.1 of [RFC5201]), it can be ignored by an end-host which means
that the host does not support or is not willing to use these that the host does not support or is not willing to use these
extensions. extensions.
With registration to a HIP relay it is usually sufficient to use UDP- With registration with a HIP relay it is usually sufficient to use
ENCAPSULATION mode of NAT traversal since the relay should not be UDP-ENCAPSULATION mode of NAT traversal since the relay should not be
behind a NAT. Thus, the relay SHOULD propose the UDP-ENCAPSULATION behind a NAT. Thus, the relay SHOULD propose the UDP-ENCAPSULATION
mode as the preferred or only mode. The NAT traversal mode mode as the preferred or only mode. The NAT traversal mode
negotiation in a HIP base exchange is illustrated in Figure 3. 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), ..)) |
|<---------------------------------------------------------------+ |<---------------------------------------------------------------+
skipping to change at page 13, line 49 skipping to change at page 13, line 49
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
silently drops the packet if the validation fails. The Responder silently drops the packet if the validation fails. The Responder
replies with an R1 packet to which it includes RELAY_TO and NAT replies with an R1 packet to which it includes RELAY_TO and NAT
traversal mode parameters. The RELAY_TO parameter MUST contain same traversal mode parameters. The RELAY_TO parameter MUST contain the
information as the RELAY_FROM parameter, i.e., the Initiator's same information as the RELAY_FROM parameter, i.e., the Initiator's
transport address, but the type of the parameter is different. The transport address, but the type of the parameter is different. The
RELAY_TO parameter is not integrity protected by the signature of the RELAY_TO parameter is not integrity protected by the signature of the
R1 to allow pre-created R1 packets at the Responder. R1 to allow pre-created R1 packets at the Responder.
In step 4, the relay receives the R1 packet. The relay drops the In step 4, the relay receives the R1 packet. The relay drops the
packet silently if the source HIT belongs to an unregistered host. packet silently if the source HIT belongs to an unregistered host.
The relay MAY verify the signature of the R1 packet and drop it if The relay MAY verify the signature of the R1 packet and drop it if
the signature is invalid. Otherwise, the relay rewrites the source the signature is invalid. Otherwise, the relay rewrites the source
address and port, and changes the destination address and port to address and port, and changes the destination address and port to
match RELAY_TO information. Finally, the relay recalculates match RELAY_TO information. Finally, the relay recalculates
skipping to change at page 17, line 33 skipping to change at page 17, line 33
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, without The I1 packet without UDP encapsulation may arrive directly, without
any relays, at the Responder. When this happens, the procedures in any relays, at the Responder. When this happens, the procedures in
[RFC5201] are followed for the rest of the base exchange. The [RFC5201] are followed for the rest of the base exchange. The
Initiator may receive multiple R1 packets, with and without UDP Initiator may receive multiple R1 packets, with and without UDP
encapsulation, from the Responder. However, after receiving a valid encapsulation, from the Responder. However, after receiving a valid
R1 and answering to it with an I2, further R1 packets that are not R1 and answering it with an I2, further R1 packets that are not
retransmits of the original R1 MUST be ignored. retransmits of the original R1 MUST be ignored.
The I1 packet without UDP encapsulation may also arrive at a HIP- The I1 packet without UDP encapsulation may also arrive at a HIP-
capable middlebox. When the middlebox is a HIP rendezvous server and capable middlebox. When the middlebox is a HIP rendezvous server and
the Responder has successfully registered to the rendezvous service, the Responder has successfully registered with the rendezvous
the middlebox follows rendezvous procedures in [RFC5204]. service, the middlebox follows rendezvous procedures in [RFC5204].
If the Initiator receives a NAT traversal mode parameter in R1 If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter without UDP encapsulation, the Initiator MAY ignore this parameter
and send an I2 without UDP encapsulation and without any selected NAT and send an I2 without UDP encapsulation and without any selected NAT
traversal mode. When the Responder receives the I2 without UDP traversal mode. When the Responder receives the I2 without UDP
encapsulation and without NAT traversal mode, it will assume that no encapsulation and without NAT traversal mode, it will assume that no
NAT traversal mechanism is needed. The packet processing will be NAT traversal mechanism is needed. The packet processing will be
done as described in [RFC5201]. The Initiator MAY store the NAT done as described in [RFC5201]. The Initiator MAY store the NAT
traversal modes for future use e.g., to be used in case of mobility traversal modes for future use e.g., in case of a mobility or
or multihoming event which causes NAT traversal to be taken in to use multihoming event which causes NAT traversal to be used during the
during the lifetime of the HIP association. lifetime of the HIP association.
4.10. Sending Control Packets after the Base Exchange 4.10. Sending Control Packets after the Base Exchange
After the base exchange, the end-hosts MAY send HIP control packets After the base exchange, the end-hosts MAY send HIP control packets
directly to each other using the transport address pair established directly to each other using the transport address pair established
for data channel without sending the control packets through the HIP for a data channel without sending the control packets through the
relay server. When a host does not get acknowledgments, e.g., to an HIP relay server. When a host does not get acknowledgments, e.g., to
UPDATE or CLOSE packet after a timeout based on local policies, the an UPDATE or CLOSE packet after a timeout based on local policies,
host SHOULD resend the packet through the relay, if it was listed in the host SHOULD resend the packet through the relay, if it was listed
the LOCATOR parameter in the base exchange. in the LOCATOR parameter in the base exchange.
If control packets are sent through a HIP relay server, the host If control packets are sent through a HIP relay server, the host
registered to the relay MUST utilize the RELAY_TO parameter like in registered with the relay MUST utilize the RELAY_TO parameter as in
the base exchange. The HIP relay server SHOULD forward HIP packets the base exchange. The HIP relay server SHOULD forward HIP packets
to the registered hosts and forward packets from a registered host to to the registered hosts and forward packets from a registered host to
the address in the RELAY_TO parameter. The relay MUST add a the address in the RELAY_TO parameter. The relay MUST add a
RELAY_FROM parameter to the control packets it relays to the RELAY_FROM parameter to the control packets it relays to the
registered hosts. registered hosts.
If the HIP relay server is not willing or able to relay a HIP packet, If the HIP relay server is not willing or able to relay a HIP packet,
it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error
notification (see Section 5.10). notification (see Section 5.10).
skipping to change at page 19, line 11 skipping to change at page 19, line 11
Figure 5: Format of UDP-encapsulated HIP Control Packets Figure 5: Format of UDP-encapsulated HIP Control Packets
HIP control packets are encapsulated in UDP packets as defined in HIP control packets are encapsulated in UDP packets as defined in
Section 2.2 of [RFC3948], "rules for encapsulating IKE messages", Section 2.2 of [RFC3948], "rules for encapsulating IKE messages",
except a different port number is used. Figure 5 illustrates the except a different port number is used. Figure 5 illustrates the
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC5201] with HIP header and parameters follow the conventions of [RFC5201] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
contains already a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC5201] includes the IP addresses in the checksum calculation. The [RFC5201] includes the IP addresses in the checksum calculation. The
NATs unaware of HIP cannot recompute the HIP checksum after changing NATs unaware of HIP cannot recompute the HIP checksum after changing
IP addresses. IP addresses.
A HIP relay server or a Responder without a relay SHOULD listen at A HIP relay server or a Responder without a relay SHOULD listen at
UDP port HIPPORT for incoming UDP-encapsulated HIP control packets. UDP 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
skipping to change at page 27, line 8 skipping to change at page 27, line 8
6.3. Base Exchange Replay Protection for HIP Relay Server 6.3. Base Exchange Replay Protection for HIP Relay Server
In certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a HIP relay attackers, can replay an earlier base exchange through a HIP relay
server by masquerading as the original Initiator and Responder. The server by masquerading as the original Initiator and Responder. The
attack does not require the attacker(s) to compromise the private attack does not require the attacker(s) to compromise the private
key(s) of the attacked host(s). However, for this attack to succeed, key(s) of the attacked host(s). However, for this attack to succeed,
the Responder has to be disconnected from the HIP relay server. the Responder has to be disconnected from the HIP relay server.
The relay can protect itself against replay attacks by involving in The relay can protect itself against replay attacks by becoming
the base exchange by introducing nonces that the end-hosts (Initiator involved in the base exchange by introducing nonces that the end-
and Responder) have to sign. One way to do this is to add hosts (Initiator and Responder) are required to sign. One way to do
ECHO_REQUEST_M parameters to the R1 and I2 packets as described in this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as
[I-D.heer-hip-middle-auth] and drop the I2 or R2 packets if the described in [I-D.heer-hip-middle-auth] and drop the I2 or R2 packets
corresponding ECHO_RESPONSE_M parameters are not present. if the corresponding ECHO_RESPONSE_M parameters are not present.
6.4. Demuxing Different HIP Associations 6.4. Demuxing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
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.
skipping to change at page 28, line 46 skipping to change at page 28, line 46
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-14 (work in progress), April 2009. draft-ietf-behave-turn-15 (work in progress), June 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 30, line 32 skipping to change at page 30, line 32
Translators (NATs)", RFC 5128, March 2008. Translators (NATs)", RFC 5128, March 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008. Communication", RFC 5207, April 2008.
Appendix A. Selecting a Value for Check Pacing Appendix A. Selecting a Value for Check Pacing
Selecting a suitable value for the connectivity check transaction Selecting a suitable value for the connectivity check transaction
pacing is essential for the performance of connectivity check-based pacing is essential for the performance of connectivity check-based
NAT traversal. The value should not be too small so that the checks NAT traversal. The value should not be so small that the checks
do not cause congestion in the network or overwhelm the NATs. On the cause network congestion or overwhelm the NATs. On the other hand, a
other hand, too high pacing value makes the checks last for a long pacing value that is too high makes the checks last for a long time,
time and thus increase the connection setup delay. thus increasing the connection setup delay.
The Ta value may be configured by the user in environments where the The Ta value may be configured by the user in environments where the
network characteristics are known beforehand. However, if the network characteristics are known beforehand. However, if the
characteristics are not know, it is recommended that the value is characteristics are not known, it is recommended that the value is
adjusted dynamically. In this case it's recommended that the hosts adjusted dynamically. In this case it's recommended that the hosts
estimate the RTT between them and set the minimum Ta value so that estimate the RTT between them and set the minimum Ta value so that
only two connectivity check messages are sent on every RTT. only two connectivity check messages are sent on every RTT.
One way to estimate the RTT is to use the time it takes for the HIP One way to estimate the RTT is to use the time it takes for the HIP
relay server registration exchange to complete; this would give an relay server registration exchange to complete; this would give an
estimate on the registering host's access link's RTT. Also the I1/R1 estimate on the registering host's access link's RTT. Also the I1/R1
exchange could be used for estimating the RTT, but since the R1 can exchange could be used for estimating the RTT, but since the R1 can
be cached in the network, or the relaying service can increase the be cached in the network, or the relaying service can increase the
delay notably, it is not recommended. delay notably, it is not recommended.
skipping to change at page 31, line 42 skipping to change at page 31, line 42
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| -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 |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
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. 20 change blocks. 
37 lines changed or deleted 39 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/