draft-ietf-hip-native-nat-traversal-00.txt   draft-ietf-hip-native-nat-traversal-01.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Experimental Ericsson Intended status: Standards Track Ericsson
Expires: March 19, 2011 September 15, 2010 Expires: August 1, 2011 January 28, 2011
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-00 draft-ietf-hip-native-nat-traversal-01
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.
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 in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on August 1, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 4 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 4
3.2. Registration Authentication . . . . . . . . . . . . . . . 4 3.2. Registration Authentication . . . . . . . . . . . . . . . 5
3.3. Forwarding Rules and Permissions . . . . . . . . . . . . . 5 3.3. Forwarding Rules and Permissions . . . . . . . . . . . . . 5
3.4. Relaying UDP Encapsulated Data and Control Packets . . . . 6 3.4. Relaying UDP Encapsulated Data and Control Packets . . . . 6
3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 6 3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 7
3.6. Base Exchange via HIP Relay Server . . . . . . . . . . . . 7 3.6. Base Exchange via HIP Relay Server . . . . . . . . . . . . 7
3.7. Native NAT Traversal Mode Negotiation . . . . . . . . . . 7 3.7. Native NAT Traversal Mode Negotiation . . . . . . . . . . 7
3.8. Connectivity Check Pacing Negotiation . . . . . . . . . . 7 3.8. Connectivity Check Pacing Negotiation . . . . . . . . . . 8
3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 7 3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8
3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 8 3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 9
3.11. Handling Conflicting SPI Values . . . . . . . . . . . . . 8 3.11. Handling Conflicting SPI Values . . . . . . . . . . . . . 9
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 9 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 9
4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 10 4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 10
4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . . 11 4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC5201] is specified to run The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is
directly on top of IPv4 or IPv6. However, many middleboxes found in specified to run directly on top of IPv4 or IPv6. However, many
the Internet, such as NATs and firewalls, often allow only UDP or TCP middleboxes found in the Internet, such as NATs and firewalls, often
traffic to pass [RFC5207]. Also, especially NATs usually require the allow only UDP or TCP traffic to pass [RFC5207]. Also, especially
host behind a NAT to create a forwarding state in the NAT before NATs usually require the host behind a NAT to create a forwarding
other hosts outside of the NAT can contact the host behind the NAT. state in the NAT before other hosts outside of the NAT can contact
To overcome this problem, different methods, commonly referred to as the host behind the NAT. To overcome this problem, different
NAT traversal techniques, have been developed. methods, commonly referred to as NAT traversal techniques, have been
developed.
Two NAT traversal techniques for HIP are specified in [RFC5770]. One Two NAT traversal techniques for HIP are specified in [RFC5770]. One
of them uses only UDP encapsulation, while the other uses also the of them uses only UDP encapsulation, while the other uses also the
Interactive Connectivity Establishment (ICE) [RFC5245] protocol, Interactive Connectivity Establishment (ICE) [RFC5245] protocol,
which in turn uses Session Traversal Utilities for NAT (STUN) which in turn uses Session Traversal Utilities for NAT (STUN)
[RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766]
protocols to achieve a reliable NAT traversal solution. protocols to achieve a reliable NAT traversal solution.
The benefit of using ICE and STUN/TURN is that one can re-use the NAT The benefit of using ICE and STUN/TURN is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
skipping to change at page 3, line 45 skipping to change at page 3, line 46
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the same terminology as [RFC5770] and the This document uses the same terminology as [RFC5770] and the
following: following:
HIP data relay: HIP data relay:
A host that forwards HIP data packets, such as Encapsulating A host that forwards HIP data packets, such as Encapsulating
Security Payload (ESP) [RFC5202], between two hosts. Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two
hosts.
Registered host: Registered host:
A host that has registered for a relaying service with a HIP data A host that has registered for a relaying service with a HIP data
relay. relay.
3. Protocol Description 3. Protocol Description
This section describes the normative behavior of the protocol This section describes the normative behavior of the protocol
extension. Most of the procedures are similar to what is defined in extension. Most of the procedures are similar to what is defined in
[RFC5770] but with different, or additional, parameter types and [RFC5770] but with different, or additional, parameter types and
values. In addition, a new type of relaying server, HIP data relay, values. In addition, a new type of relaying server, HIP data relay,
is specified. is specified. Also, it should be noted that HIP version 2
[I-D.ietf-hip-rfc5201-bis] (instead of [RFC5201] used in [RFC5770])
is expected to be used with this NAT traversal mode.
3.1. Relay Registration 3.1. Relay Registration
Relay registration procedure for HIP signaling is identical to the Relay registration procedure for HIP signaling is identical to the
one specified in Section 4.1 of [RFC5770]. However, a host MAY also one specified in Section 4.1 of [RFC5770]. However, a host MAY also
register for UDP encapsulated ESP relaying using Registration Type register for UDP encapsulated ESP relaying using Registration Type
RELAY_UDP_ESP (value [TBD by IANA: 3]). RELAY_UDP_ESP (value [TBD by IANA: 3]).
If the HIP relay server supports relaying of UDP encapsulated ESP, If the HIP relay server supports relaying of UDP encapsulated ESP,
the host is allowed to register for data relaying service (see the host is allowed to register for data relaying service (see
skipping to change at page 5, line 27 skipping to change at page 5, line 38
HI of the registering host is in the allowed list for all the HI of the registering host is in the allowed list for all the
Registration Types in the REG_REQUEST parameter. If the host is in Registration Types in the REG_REQUEST parameter. If the host is in
the allowed list (or the relay does not require any authentication), the allowed list (or the relay does not require any authentication),
the relay MUST proceed with the registration. the relay MUST proceed with the registration.
If the host was not in the allowed list and the relay requires the If the host was not in the allowed list and the relay requires the
host to authenticate, the relay MUST check whether the packet also host to authenticate, the relay MUST check whether the packet also
contains a CERT parameter. If the packet does not contain a CERT contains a CERT parameter. If the packet does not contain a CERT
parameter, the server MUST reject the registrations requiring parameter, the server MUST reject the registrations requiring
authentication with Failure Type 0 (Registration requires additional authentication with Failure Type 0 (Registration requires additional
credentials) [RFC5203]. If the certificate is valid and accepted credentials) [I-D.ietf-hip-rfc5203-bis]. If the certificate is valid
(issued for the registering host and signed by a trusted issuer), the and accepted (issued for the registering host and signed by a trusted
relay MUST proceed with the registration. If the certificate in the issuer), the relay MUST proceed with the registration. If the
parameter is not accepted, the relay MUST reject the corresponding certificate in the parameter is not accepted, the relay MUST reject
registrations with Failure Type [TBD by IANA: 3] (Invalid the corresponding registrations with Failure Type [TBD by IANA: 3]
certificate). (Invalid certificate).
3.3. Forwarding Rules and Permissions 3.3. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before any ESP data packets sent by a peer are forwarded, a before any ESP data packets sent by a peer are forwarded, a
permission MUST be set for the peer's address. The permissions also permission MUST be set for the peer's address. The permissions also
install a forwarding rule, similar to TURN's channels, based on the install a forwarding rule, similar to TURN's channels, based on the
Security Parameter Index (SPI) values in the ESP packets. Security Parameter Index (SPI) values in the ESP packets.
Permissions are not required for the connectivity checks, but if a Permissions are not required for the connectivity checks, but if a
relayed address is selected to be used for data, the registered host relayed address is selected to be used for data, the registered host
MUST send an UPDATE message [RFC5201] with a PEER_PERMISSION MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a
parameter (see Section 4.2) with the address of the peer and the PEER_PERMISSION parameter (see Section 4.2) with the address of the
outbound and inbound SPI values the host is using with this peer. peer and the outbound and inbound SPI values the host is using with
this peer.
When a data relay receives an UPDATE with a PEER_PERMISSION When a data relay receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the relay checks if there is registered. If the host was registered, the relay checks if there is
a permission with matching information (address, protocol, port and a permission with matching information (address, protocol, port and
SPI values). If there is no such permission, a new permission MUST SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
skipping to change at page 8, line 34 skipping to change at page 8, line 47
After a working candidate pair, or pairs, have been discovered, the After a working candidate pair, or pairs, have been discovered, the
controlling host MUST conclude the checks by nominating the highest controlling host MUST conclude the checks by nominating the highest
priority candidate pair for use. The pair MUST be nominated by priority candidate pair for use. The pair MUST be nominated by
sending an ESP packet on the selected pair. If the controlling host sending an ESP packet on the selected pair. If the controlling host
does not have any data to send, it SHOULD send an ICMP echo request does not have any data to send, it SHOULD send an ICMP echo request
using the nominated pair to signal to the controlled host that it can using the nominated pair to signal to the controlled host that it can
stop checks and start using the nominated pair. stop checks and start using the nominated pair.
If the connectivity checks failed the hosts SHOULD notify each other If the connectivity checks failed the hosts SHOULD notify each other
about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message
[RFC5770]. Type [RFC5770].
3.10. NAT Keepalives 3.10. NAT Keepalives
To keep the NAT bindings towards the HIP relay server and the HIP To keep the NAT bindings towards the HIP relay server and the HIP
data relay alive, if a registered host has not sent any data or data relay alive, if a registered host has not sent any data or
control messages to the relay for 15 seconds, it MUST send a HIP control messages to the relay for 15 seconds, it MUST send a HIP
NOTIFY packet to the relay. Likewise, if the host has not sent any NOTIFY packet to the relay. Likewise, if the host has not sent any
data to a host it has security association and has run connectivity data to a host it has security association and has run connectivity
checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo
request using the same locators as the security association is using. request using the same locators as the security association is using.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 1: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters Figure 1: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
4.2. PEER_PERMISSION Parameter 4.2. PEER_PERMISSION Parameter
The format of the PEER_PERMISSION parameter is shown in Figure 2. The format of the PEER_PERMISSION parameter is shown in Figure 2.
The parameter is used for setting up and refreshing forwarding rules The parameter is used for setting up and refreshing forwarding rules
and permissions at the data relay for data packets. The parameter and permissions at the data relay for data packets. The parameter
contains one or more sets of Port, Protocol, Address, Outbound SPI, contains one or more sets of Port, Protocol, Address, Outbound SPI
and Inbound SPI values. One set defines a rule for one peer address. (OSPI), and Inbound SPI (ISPI) values. One set defines a rule for
one peer address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
skipping to change at page 11, line 43 skipping to change at page 11, line 43
IPv6 address" format, of the peer IPv6 address" format, of the peer
OSPI the outbound SPI value the registered host is using for OSPI the outbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
ISPI the inbound SPI value the registered host is using for ISPI the inbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
Figure 2: Format of the PEER_PERMISSION Parameter Figure 2: Format of the PEER_PERMISSION Parameter
4.3. HIP Connectivity Check Packets 4.3. HIP Connectivity Check Packets
The connectivity request messages are HIP UPDATE packets with The connectivity request messages are HIP UPDATE packets with a
CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets CANDIDATE_PRIORITY parameter (Figure 3). Response UPDATE packets
contain a MAPPED_ADDRESS parameter (Figure 1). contain a MAPPED_ADDRESS parameter (Figure 1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4700] Type [TBD by IANA; 4700]
Length 4 Length 4
Priority the priority of a peer reflexive candidate Priority the priority of a (potential) peer reflexive candidate
Figure 3: Format of the CANDIDATE_PRIORITY Parameter Figure 3: Format of the CANDIDATE_PRIORITY Parameter
5. Security Considerations 5. Security Considerations
Same security considerations as with [RFC5770] apply also to this NAT Same security considerations as with [RFC5770] apply also to this NAT
traversal mode. traversal mode.
If the data relay uses the same relayed address and port for multiple If the data relay uses the same relayed address and port for multiple
registered hosts, it appears to all the peers, and their firewalls, registered hosts, it appears to all the peers, and their firewalls,
skipping to change at page 12, line 48 skipping to change at page 12, line 48
HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin
Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav
Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip
Matthews. Matthews.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type values for the new HIP [I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values
Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Section 4.1), for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined
and PEER_PERMISSION (defined in Section 4.2). in Section 4.1), and PEER_PERMISSION (defined in Section 4.2).
This document also updates the IANA Registry for HIP NAT traversal This document also updates the IANA Registry for HIP NAT traversal
modes [RFC5770] by assigning value for the NAT traversal mode ICE- modes [RFC5770] by assigning value for the NAT traversal mode ICE-
HIP-UDP (defined in Section 3.7). HIP-UDP (defined in Section 3.7).
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC5203] that allow registering with a HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow
relay server for ESP relaying service: RELAY_UDP_ESP (defined in registering with a HIP relay server for ESP relaying service:
Section 3.1); and performing server reflexive candidate discovery: RELAY_UDP_ESP (defined in Section 3.1); and performing server
CANDIDATE_DISCOVERY (defined in Section 3.5). reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in
Section 3.5).
The IANA Registry for HIP Registration Failure Types is updated with The IANA Registry for HIP Registration Failure Types is updated with
new Failure Types "Insufficient resources" (defined in Section 3.1) new Failure Types "Insufficient resources" (defined in Section 3.1)
and "Invalid certificate" (defined in Section 3.2). and "Invalid certificate" (defined in Section 3.2).
8. References 8. References
8.1. Normative References 8.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [I-D.ietf-hip-rfc5201-bis]
"Host Identity Protocol", RFC 5201, April 2008. Moskowitz, R., Jokela, P., Henderson, T., and T. Heer,
"Host Identity Protocol", draft-ietf-hip-rfc5201-bis-04
(work in progress), January 2011.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [I-D.ietf-hip-rfc5202-bis]
Encapsulating Security Payload (ESP) Transport Format with Jokela, P., Moskowitz, R., Nikander, P., and J. Melen,
the Host Identity Protocol (HIP)", RFC 5202, April 2008. "Using the Encapsulating Security Payload (ESP) Transport
Format with the Host Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in progress),
September 2010.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity [I-D.ietf-hip-rfc5203-bis]
Protocol (HIP) Registration Extension", RFC 5203, Laganier, J., Koponen, T., and L. Eggert, "Host Identity
April 2008. Protocol (HIP) Registration Extension",
draft-ietf-hip-rfc5203-bis-00 (work in progress),
August 2010.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] 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", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[I-D.ietf-hip-cert] [I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "HIP Certificates", Heer, T. and S. Varjonen, "Host Identity Protocol
draft-ietf-hip-cert-03 (work in progress), April 2010. Certificates", draft-ietf-hip-cert-09 (work in progress),
January 2011.
8.2. Informative References 8.2. Informative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 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.
[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.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
 End of changes. 26 change blocks. 
64 lines changed or deleted 76 lines changed or added

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