draft-ietf-hip-native-nat-traversal-25.txt   draft-ietf-hip-native-nat-traversal-26.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track M. Komu, Ed. Intended status: Standards Track M. Komu, Ed.
Expires: June 11, 2018 Ericsson Expires: June 23, 2018 Ericsson
December 8, 2017 December 20, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-25 draft-ietf-hip-native-nat-traversal-26
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2018. This Internet-Draft will expire on June 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 17 skipping to change at page 3, line 17
6.4. Demultiplexing Different HIP Associations . . . . . . . . 50 6.4. Demultiplexing Different HIP Associations . . . . . . . . 50
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 50 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 50
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 50 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 50
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 50 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 54 10.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 54 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 54
Appendix B. Differences with respect to ICE . . . . . . . . . . 55 Appendix B. Differences with respect to ICE . . . . . . . . . . 55
Appendix C. Differences to Base Exchange and UPDATE procedures . 57 Appendix C. Differences to Base Exchange and UPDATE procedures . 56
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 59 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in directly on top of IPv4 or IPv6. However, many middleboxes found in
the Internet, such as NATs and firewalls, often allow only UDP or TCP the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, especially NATs usually require the traffic to pass [RFC5207]. Also, especially NATs usually require the
host behind a NAT to create a forwarding state in the NAT before host behind a NAT to create a forwarding state in the NAT before
skipping to change at page 9, line 41 skipping to change at page 9, line 41
succeeds, no HIP connectivity checks or UDP encapsulation of ESP are succeeds, no HIP connectivity checks or UDP encapsulation of ESP are
needed. needed.
4. Protocol Description 4. Protocol Description
This section describes the normative behavior of the "Native ICE-HIP" This section describes the normative behavior of the "Native ICE-HIP"
protocol extension. Most of the procedures are similar to what is protocol extension. Most of the procedures are similar to what is
defined in [RFC5770] but with different, or additional, parameter defined in [RFC5770] but with different, or additional, parameter
types and values. In addition, a new type of relaying server, Data types and values. In addition, a new type of relaying server, Data
Relay Server, is specified. Also, it should be noted that HIP Relay Server, is specified. Also, it should be noted that HIP
version 2 [RFC7401] (instead of [RFC5201] used in [RFC5770]) is version 2 [RFC7401] instead of HIPv1 is expected to be used with this
expected to be used with this NAT traversal mode. NAT traversal mode.
4.1. Relay Registration 4.1. Relay Registration
In order for two hosts to communicate over NATted environments, they In order for two hosts to communicate over NATted environments, they
need a reliable way to exchange information. To achieve this, "HIP need a reliable way to exchange information. To achieve this, "HIP
Relay Server" is defined in [RFC5770]. It supports relaying of HIP Relay Server" is defined in [RFC5770]. It supports relaying of HIP
control plane traffic over UDP in NATted environments, and forwards control plane traffic over UDP in NATted environments, and forwards
HIP control packets between the Initiator and the Responder. In this HIP control packets between the Initiator and the Responder. In this
document, the HIP Relay Server is denoted as "Control Relay Server" document, the HIP Relay Server is denoted as "Control Relay Server"
for better alignment with the rest of the terminology. The for better alignment with the rest of the terminology. The
skipping to change at page 12, line 28 skipping to change at page 12, line 28
extensions are described in Section 4.10. extensions are described in Section 4.10.
The Data Relay Client MUST maintain an active HIP association with The Data Relay Client MUST maintain an active HIP association with
the Data Relay Server as long as it requires the data relaying the Data Relay Server as long as it requires the data relaying
service. When the HIP association is closed (or times out), or the service. When the HIP association is closed (or times out), or the
registration lifetime passes without the Data Relay Client refreshing registration lifetime passes without the Data Relay Client refreshing
the registration, the Data Relay Server MUST stop relaying packets the registration, the Data Relay Server MUST stop relaying packets
for that host and close the corresponding UDP port (unless other Data for that host and close the corresponding UDP port (unless other Data
Relay Clients are still using it). Relay Clients are still using it).
The Data Relay Server MAY use the same relayed address and port for The Data Relay Server SHOULD offer a different relayed address and
multiple Data Relay Clients, but since this can cause problems with port for each Data Relay Client because this can cause problems with
stateful firewalls (see Section 6.5) it is NOT RECOMMENDED. stateful firewalls (see Section 6.5).
When a Control Relay Client sends an UPDATE (e.g., due to host When a Control Relay Client sends an UPDATE (e.g., due to host
movement or to renew service registration), the Control Relay Server movement or to renew service registration), the Control Relay Server
MUST follow the general guidelines defined in [RFC8003], with the MUST follow the general guidelines defined in [RFC8003], with the
difference that all UPDATE messages are delivered on top of UDP. In difference that all UPDATE messages are delivered on top of UDP. In
addition to this, the Control Relay Server MUST include the REG_FROM addition to this, the Control Relay Server MUST include the REG_FROM
parameter in all UPDATE responses sent to the Control Relay Client. parameter in all UPDATE responses sent to the Control Relay Client.
This applies both renewals of service registration but also to host This applies both renewals of service registration but also to host
movement, where especially the latter requires the Control Relay movement, where especially the latter requires the Control Relay
Client to learn its new server reflexive address candidate. Client to learn its new server reflexive address candidate.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
available, or if the host has just a single interface and no STUN or available, or if the host has just a single interface and no STUN or
Data Relay Server are available. Data Relay Server are available.
Each local address candidate MUST be assigned a priority. The Each local address candidate MUST be assigned a priority. The
following recommended formula (as described in following recommended formula (as described in
[I-D.ietf-ice-rfc5245bis]) SHOULD be used: [I-D.ietf-ice-rfc5245bis]) SHOULD be used:
priority = (2^24)*(type preference) + (2^8)*(local preference) + priority = (2^24)*(type preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID) (2^0)*(256 - component ID)
In the formula, type preference follows the ICE specification section In the formula, type preference follows the ICE specification
4.1.2.2 guidelines: the RECOMMENDED values are 126 for host guidelines: the RECOMMENDED values are 126 for host candidates, 100
candidates, 100 for server reflexive candidates, 110 for peer for server reflexive candidates, 110 for peer reflexive candidates,
reflexive candidates, and 0 for relayed candidates. The highest and 0 for relayed candidates. The highest value is 126 (the most
value is 126 (the most preferred) and lowest is 0 (last resort). For preferred) and lowest is 0 (last resort). For all candidates of the
all candidates of the same type, the preference type value MUST be same type, the preference type value MUST be identical, and,
identical, and, correspondingly, the value MUST be different for correspondingly, the value MUST be different for different types.
different types. For peer reflexive values, the type preference For peer reflexive values, the type preference value MUST be higher
value MUST be higher than for server reflexive types. It should be than for server reflexive types. It should be noted that peer
noted that peer reflexive values are learned later during reflexive values are learned later during connectivity checks, so a
connectivity checks, so a host cannot employ it during candidate host cannot employ it during candidate gathering stage yet.
gathering stage yet.
Following the ICE specification, the local preference MUST be an Following the ICE specification, the local preference MUST be an
integer from 0 (lowest preference) to 65535 (highest preference) integer from 0 (lowest preference) to 65535 (highest preference)
inclusive. In the case the host has only a single address candidate, inclusive. In the case the host has only a single address candidate,
the value SHOULD be 65535. In the case of multiple candidates, each the value SHOULD be 65535. In the case of multiple candidates, each
local preference value MUST be unique. Dual-stack considerations for local preference value MUST be unique. Dual-stack considerations for
IPv6 in ICE apply also here. IPv6 in ICE apply also here.
Unlike ICE, this protocol only creates a single UDP flow between the Unlike ICE, this protocol only creates a single UDP flow between the
two communicating hosts, so only a single component exists. Hence, two communicating hosts, so only a single component exists. Hence,
skipping to change at page 27, line 41 skipping to change at page 27, line 41
Initiator sends an I1 message over UDP and the Responder responds Initiator sends an I1 message over UDP and the Responder responds
with an R1 message over UDP without including any NAT traversal mode with an R1 message over UDP without including any NAT traversal mode
parameter. The rest of the base exchange follows the procedures parameter. The rest of the base exchange follows the procedures
defined in [RFC7401], except that the control and data plane use UDP defined in [RFC7401], except that the control and data plane use UDP
encapsulation. Here, the use of UDP for NAT traversal is agreed encapsulation. Here, the use of UDP for NAT traversal is agreed
implicitly. This way of operation is still subject to NAT timeouts, implicitly. This way of operation is still subject to NAT timeouts,
and the hosts MUST employ NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
When UDP-ENCAPSULATION mode is chosen either explicitly or When UDP-ENCAPSULATION mode is chosen either explicitly or
implicitly, the connectivity checks as defined in this document MUST implicitly, the connectivity checks as defined in this document MUST
not be used. When hosts lose connectivity, they MUST instead utilize NOT be used. When hosts lose connectivity, they MUST instead utilize
[RFC8046] or [RFC8047] procedures, but with the difference being that [RFC8046] or [RFC8047] procedures, but with the difference being that
UDP-based tunneling MUST be employed for the entire lifetime of the UDP-based tunneling MUST be employed for the entire lifetime of the
corresponding Host Association. corresponding Host Association.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is
applicable also in the context of this specification, so it is applicable also in the context of this specification, so it is
repeated here for completeness. repeated here for completeness.
skipping to change at page 51, line 26 skipping to change at page 51, line 26
[I-D.ietf-ice-rfc5245bis] describes attacks on relayed candidate [I-D.ietf-ice-rfc5245bis] describes attacks on relayed candidate
gathering. Similarly to ICE TURN servers, Data Relay Server require gathering. Similarly to ICE TURN servers, Data Relay Server require
an authenticated base exchange that protects relayed address an authenticated base exchange that protects relayed address
gathering against fake requests and responses. Further, replay gathering against fake requests and responses. Further, replay
attacks are not possible because the HIP base exchange (and also attacks are not possible because the HIP base exchange (and also
UPDATE procedure) is protected against replay attacks. UPDATE procedure) is protected against replay attacks.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC8126].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC7401] by assigning new HIP Parameter Type values for the new HIP [RFC7401] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in
Section 5.12), and PEER_PERMISSION (defined in Section 5.13). Section 5.12), and PEER_PERMISSION (defined in Section 5.13).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
traversal mode ICE-HIP-UDP (defined in Section 5.4) This traversal mode ICE-HIP-UDP (defined in Section 5.4) This
specification introduces a new keepalive Notify message type field specification introduces a new keepalive Notify message type field
skipping to change at page 52, line 34 skipping to change at page 52, line 34
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <https://www.rfc-editor.org/info/rfc7401>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003, Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>. October 2016, <https://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <http://www.rfc-editor.org/info/rfc8004>. October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046, with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017, <https://www.rfc- DOI 10.17487/RFC8046, February 2017, <https://www.rfc-
editor.org/info/rfc8046>. editor.org/info/rfc8046>.
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
Multihoming with the Host Identity Protocol", RFC 8047, Multihoming with the Host Identity Protocol", RFC 8047,
DOI 10.17487/RFC8047, February 2017, <https://www.rfc- DOI 10.17487/RFC8047, February 2017, <https://www.rfc-
editor.org/info/rfc8047>. editor.org/info/rfc8047>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010,
<http://www.rfc-editor.org/info/rfc5770>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5389>. editor.org/info/rfc5389>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7402>. editor.org/info/rfc7402>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Writing an IANA Considerations Section in RFCs", BCP 26,
DOI 10.17487/RFC5226, May 2008, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc8126>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-08 (work in progress), December 2016. rfc5245bis-15 (work in progress), November 2017.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
10.2. Informative References 10.2. Informative References
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>. 2006, <https://www.rfc-editor.org/info/rfc4423>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
Henderson, "Host Identity Protocol", RFC 5201, and W. Weiss, "An Architecture for Differentiated
DOI 10.17487/RFC5201, April 2008, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc5201>. <https://www.rfc-editor.org/info/rfc2475>.
[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, DOI 10.17487/RFC5207, April Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <http://www.rfc-editor.org/info/rfc5207>. 2008, <https://www.rfc-editor.org/info/rfc5207>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <http://www.rfc-editor.org/info/rfc6538>. March 2012, <https://www.rfc-editor.org/info/rfc6538>.
[MMUSIC-ICE] [MMUSIC-ICE]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", Work in Progress, July 2008. Protocol (SIP) Protocols", Work in Progress, July 2008.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <https://www.rfc-editor.org/info/rfc5128>.
[HIP-MIDDLE] [HIP-MIDDLE]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Work in Progress, Authentication for HIP Middleboxes", Work in Progress,
February 2009. February 2009.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<http://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
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 so small that the checks NAT traversal. The value should not be so small that the checks
cause network congestion or overwhelm the NATs. On the other hand, a cause network congestion or overwhelm the NATs. On the other hand, a
pacing value that is too high makes the checks last for a long time, pacing value that is too high makes the checks last for a long time,
thus increasing the connection setup delay. thus increasing the connection setup delay.
 End of changes. 27 change blocks. 
60 lines changed or deleted 54 lines changed or added

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