draft-ietf-hip-reload-instance-03.txt   draft-ietf-hip-reload-instance-04.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Experimental J. Maenpaa Intended status: Experimental J. Maenpaa
Expires: July 15, 2011 Ericsson Expires: April 30, 2012 Ericsson
January 11, 2011 October 28, 2011
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD) Instance Specification for REsource LOcation And Discovery (RELOAD)
draft-ietf-hip-reload-instance-03.txt draft-ietf-hip-reload-instance-04.txt
Abstract Abstract
This document is the Host Identity Protocol-Based Overlay Networking This document is the Host Identity Protocol-Based Overlay Networking
Environment (HIP BONE) instance specification for the REsource Environment (HIP BONE) instance specification for the REsource
LOcation And Discovery (RELOAD) protocol. The document provides the LOcation And Discovery (RELOAD) protocol. The document provides the
details needed to build a RELOAD-based overlay that uses HIP. details needed to build a RELOAD-based overlay that uses HIP.
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 April 30, 2012.
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 July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . . 3 4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . . 3
5. Mapping between Protocol Primitives and HIP Messages . . . . . 4 5. Mapping between Protocol Primitives and HIP Messages . . . . . 4
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5
6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5 6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5
7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6
8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 8 10. RELOAD Overlay Configuration Document Extension . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9
14.2. Informational References . . . . . . . . . . . . . . . . . 10 14.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The HIP BONE (Host Identify Protocol-Based Overlay Networking The HIP BONE (Host Identify Protocol-Based Overlay Networking
Environment) specification [I-D.ietf-hip-bone] provides a high-level Environment) specification [RFC6079] provides a high-level framework
framework for building HIP-based [RFC5201] overlays. The HIP BONE for building HIP-based [RFC5201] overlays. The HIP BONE framework
framework leaves the specification of the details on how to combine a leaves the specification of the details on how to combine a
particular peer protocol with HIP to build an overlay up to documents particular peer protocol with HIP to build an overlay up to documents
referred to as HIP BONE instance specifications. As discussed in referred to as HIP BONE instance specifications. As discussed in
[I-D.ietf-hip-bone], a HIP BONE instance specification needs to [RFC6079], a HIP BONE instance specification needs to define,
define, minimally: minimally:
o the peer protocol to be used. o the peer protocol to be used.
o what kind of Node IDs are used and how they are derived. o what kind of Node IDs are used and how they are derived.
o which peer protocol primitives trigger HIP messages. o which peer protocol primitives trigger HIP messages.
o how the overlay identifier is generated. o how the overlay identifier is generated.
This document addresses all the previous items and provides This document addresses all the previous items and provides
additional details needed to built RELOAD-based HIP BONEs. The additional details needed to built RELOAD-based HIP BONEs. The
details on how different RELOAD modules would be integrated to a HIP details on how different RELOAD modules would be integrated to a HIP
implementation and what kind of APIs are used between them are left implementation and what kind of APIs are used between them are left
as implementation details or to be defined by other documents. as implementation details or to be defined by other documents.
2. Terminology 2. Terminology
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].
In addition, this document uses the terms defined in [RFC5201], In addition, this document uses the terms defined in [RFC5201],
[I-D.ietf-hip-bone], [RFC6028], and [I-D.ietf-p2psip-base]. [RFC6079], [RFC6028], and [I-D.ietf-p2psip-base].
3. Peer Protocol 3. Peer Protocol
The peer protocol to be used is RELOAD, which is specified in The peer protocol to be used is RELOAD, which is specified in
[I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the
RELOAD's Forwarding and Link Management Layer (described in Section RELOAD's Forwarding and Link Management Layer (described in Section
5.5. of [I-D.ietf-p2psip-base]). 5.5. of [I-D.ietf-p2psip-base]).
4. Node ID Generation 4. Node ID Generation
skipping to change at page 4, line 25 skipping to change at page 4, line 25
of connection establishment with the HIP base exchange, whereas the of connection establishment with the HIP base exchange, whereas the
rest of the RELOAD messages are conveyed within HIP messages. The rest of the RELOAD messages are conveyed within HIP messages. The
Forwarding and Link Management Layer functionality of RELOAD defined Forwarding and Link Management Layer functionality of RELOAD defined
in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT
traversal functionality, is replaced by HIP and the extensions traversal functionality, is replaced by HIP and the extensions
defined in this document. defined in this document.
The standard RELOAD messages consist of three parts: Forwarding The standard RELOAD messages consist of three parts: Forwarding
Header, Message Contents and the Security Block. When RELOAD Header, Message Contents and the Security Block. When RELOAD
messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message
Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups] Contents are used as such within HIP DATA [RFC6078] messages, but the
messages, but the functionality of the Forwarding Header and Security functionality of the Forwarding Header and Security Block are
Block are replaced with HIP header, HIP Destination and Via lists replaced with HIP header, HIP Destination and Via lists [RFC6028],
[RFC6028], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID and CERT [RFC6253], TRANSACTION_ID [RFC6078], OVERLAY_ID and
[I-D.ietf-hip-hiccups], OVERLAY_ID and OVERLAY_TTL OVERLAY_TTL [RFC6079] parameters.
[I-D.ietf-hip-bone] parameters.
5.1. Forwarding Header 5.1. Forwarding Header
The RELOAD Forwarding Header is used for forwarding messages between The RELOAD Forwarding Header is used for forwarding messages between
peers and to their final destination. The Forwarding Header's peers and to their final destination. The Forwarding Header's
overlay field's value MUST be used as such in an OVERLAY_ID parameter overlay field's value MUST be used as such in an OVERLAY_ID parameter
and the transaction_id field in a TRANSACTION_ID parameter. That is, and the transaction_id field in a TRANSACTION_ID parameter. That is,
all RELOAD HIP BONE messages MUST contain these parameters and the all RELOAD HIP BONE messages MUST contain these parameters and the
length of the OVERLAY_ID parameter's identifier field is 4 and the length of the OVERLAY_ID parameter's identifier field is 4 and the
length of the TRANSACTION_ID's identifier 8 octets. HIP Destination length of the TRANSACTION_ID's identifier 8 octets. HIP Destination
skipping to change at page 5, line 12 skipping to change at page 5, line 12
needed with HIP and options field, if needed eventually for some needed with HIP and options field, if needed eventually for some
extensions, can be replaced with additional HIP parameters. extensions, can be replaced with additional HIP parameters.
5.2. Security Block 5.2. Security Block
The RELOAD Security Block contains certificates and digital The RELOAD Security Block contains certificates and digital
signatures of the message. All the HIP DATA messages are digitally signatures of the message. All the HIP DATA messages are digitally
signed by the originator of the message and contain the HOST_ID signed by the originator of the message and contain the HOST_ID
parameter with the identifier that can be used for verifying the parameter with the identifier that can be used for verifying the
signature. Certificates are delivered in a HIP CERT parameter as signature. Certificates are delivered in a HIP CERT parameter as
defined in [I-D.ietf-hip-cert] or stored to the overlay using the defined in [RFC6253] or stored to the overlay using the RELOAD
RELOAD Certificate Storage Usage. Certificate Storage Usage.
Note that when the RELOAD mode for Node ID generation is used, the Note that when the RELOAD mode for Node ID generation is used, the
certificate certifying that a host is allowed to use a certain Node certificate certifying that a host is allowed to use a certain Node
ID MUST contain host's Node ID instead of HIT in the "Subject ID MUST contain host's Node ID instead of HIT in the "Subject
Alternative Name" of the certificate as described in Section 10.3 of Alternative Name" of the certificate as described in Section 10.3 of
[I-D.ietf-p2psip-base] while the "Subject" field contains the HIT [I-D.ietf-p2psip-base] while the "Subject" field contains the HIT
calculated from the Host Identity. calculated from the Host Identity.
5.3. Replaced RELOAD Messages 5.3. Replaced RELOAD Messages
skipping to change at page 6, line 8 skipping to change at page 6, line 8
6. Securing Communication 6. Securing Communication
RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop
messaging and certificates and signatures for providing integrity messaging and certificates and signatures for providing integrity
protection for the overlay messages and for the data stored in the protection for the overlay messages and for the data stored in the
overlay. overlay.
With a RELOAD HIP BONE, instead of using TLS connections as defined With a RELOAD HIP BONE, instead of using TLS connections as defined
in [I-D.ietf-p2psip-base], all HIP overlay messages SHOULD be either in [I-D.ietf-p2psip-base], all HIP overlay messages SHOULD be either
sent using encrypted connections (such as IPsec ESP tunnel between sent using encrypted connections (such as IPsec ESP tunnel between
two peers) or the contents of the messages SHOULD be in an ENCRYPTED two peers [RFC6261]) or the contents of the messages SHOULD be in an
parameter (see Section 5.2.15 of [RFC5201]). Use of encrypted ENCRYPTED parameter (see Section 5.2.15 of [RFC5201]). Use of
connections is RECOMMENDED since that provides confidentiality also encrypted connections is RECOMMENDED since that provides
for the HIP headers. confidentiality also for the HIP headers.
The data objects stored in the RELOAD HIP BONE overlay are signed and The data objects stored in the RELOAD HIP BONE overlay are signed and
the signatures are stored as defined in [I-D.ietf-p2psip-base] with the signatures are stored as defined in [I-D.ietf-p2psip-base] with
the exception that SignerIdentity is carried in the HIP DATA the exception that SignerIdentity is carried in the HIP DATA
message's HOST_ID parameter instead of using the RELOAD message's HOST_ID parameter instead of using the RELOAD
SecurityBlock. If certificates are needed, they are sent using the SecurityBlock. If certificates are needed, they are sent using the
CERT parameter. CERT parameter.
7. Routing HIP Messages via the Overlay 7. Routing HIP Messages via the Overlay
skipping to change at page 7, line 11 skipping to change at page 7, line 11
[I-D.ietf-p2psip-base]. If the HIP packet generates a response, the [I-D.ietf-p2psip-base]. If the HIP packet generates a response, the
response is routed back on the same path using the ROUTE_DST response is routed back on the same path using the ROUTE_DST
parameter as specified in [RFC6028]. parameter as specified in [RFC6028].
8. Enrollment and Bootstrapping 8. Enrollment and Bootstrapping
The RELOAD HIP BONE instance uses the enrollment and bootstrap The RELOAD HIP BONE instance uses the enrollment and bootstrap
procedure defined by RELOAD [I-D.ietf-p2psip-base] with the procedure defined by RELOAD [I-D.ietf-p2psip-base] with the
exceptions listed below. exceptions listed below.
o In RELOAD, a node wishing to enroll in an overlay starts with a o In RELOAD, a node wishing to enroll in an overlay starts with
discovery process to find an enrollment server as explained in obtaining a configuration document as explained in
[I-D.ietf-p2psip-base]. The URL of the enrollment server may be [I-D.ietf-p2psip-base]. This specification extends the RELOAD
provided by an out-of-band mechanism or alternatively, the node overlay configuration document as defined in Section 10.
can do a DNS SRV query to find an enrollment server. In the
RELOAD HIP BONE instance, instead of doing a DNS SRV query using a
service name of "p2psip_enroll" to find an enrollment server, the
service name "hipbreload_enr" is used. The URL of the enrollment
server is formed by appending a path of "hipbone-reload/enroll" to
the overlay name. After this, the enrollment and bootstrap
procedure continues as defined in RELOAD base
[I-D.ietf-p2psip-base], that is, the overlay configuration
document is fetched from the enrollment server.
o The X.509 certificates used by the RELOAD HIP BONE instance are o The X.509 certificates used by the RELOAD HIP BONE instance are
similar to those of RELOAD except that they contain HITs instead similar to those of RELOAD except that they contain HITs instead
of RELOAD URIs. The HITs are included in the SubjectAltName field of RELOAD URIs. The HITs are included in the SubjectAltName field
of the certificate as described in [I-D.ietf-hip-cert]. of the certificate as described in [RFC6253].
o When contacting a bootstrap node, instead of forming a DTLS or TLS o When contacting a bootstrap node, instead of forming a DTLS or TLS
connection, the host MUST perform a HIP base exchange with the connection, the host MUST perform a HIP base exchange with the
bootstrap node. The base exchange MAY be performed using a HIP bootstrap node. The base exchange MAY be performed using a HIP
rendezvous or relay server. rendezvous or relay server.
This instance specification extends the RELOAD overlay configuration
document by adding a new element and attribute. These changes are
listed in Section 10.
9. NAT Traversal 9. NAT Traversal
RELOAD relies on the Forwarding and Link Management Layer providing RELOAD relies on the Forwarding and Link Management Layer providing
NAT traversal capabilities. Thus, the RELOAD HIP BONE instance NAT traversal capabilities. Thus, the RELOAD HIP BONE instance
implementations MUST implement some reliable NAT traversal mechanism. implementations MUST implement some reliable NAT traversal mechanism.
To maximize interoperability, all implementations SHOULD implement at To maximize interoperability, all implementations SHOULD implement at
least [RFC5770]. least [RFC5770].
HIP relay servers are not necessarily needed with this HIP BONE HIP relay servers are not necessarily needed with this HIP BONE
instance since the overlay network can be used for relaying the Base instance since the overlay network can be used for relaying the Base
skipping to change at page 8, line 23 skipping to change at page 8, line 15
hit: The HIT of the bootstrap node. hit: The HIT of the bootstrap node.
If the bootstrap-node element does not contain a HIT, opportunistic If the bootstrap-node element does not contain a HIT, opportunistic
mode SHOULD be used for contacting the bootstrap node. If the mode SHOULD be used for contacting the bootstrap node. If the
element does not contain a port number, the bootstrap node SHOULD be element does not contain a port number, the bootstrap node SHOULD be
contacted by starting the base exchange as defined in [RFC5201]. contacted by starting the base exchange as defined in [RFC5201].
Otherwise, the base exchange MUST be started UDP-encapsulated as Otherwise, the base exchange MUST be started UDP-encapsulated as
defined in [RFC5770] using the given port as the destination port defined in [RFC5770] using the given port as the destination port
number. number.
A RELOAD HIP BONE overlay MUST use Overlay Link Protocol type "HIP"
in the configuration document's overlay-link-protocol element. The
enrolling node MUST check the overlay-link-protocol element and
proceed with procedures defined in this document only if "HIP" link
type is found.
This document also adds a new element inside the configuration This document also adds a new element inside the configuration
element that defines which mode (see Section 4) is used for element that defines which mode (see Section 4) is used for
generating the Node and Resource IDs. The name of the element is generating the Node and Resource IDs. The name of the element is
"hipbone-id-mode" and the content is the identifier of the mode: "hipbone-id-mode" and the content is the identifier of the mode:
"ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that
use the whole 128 bits as defined by the RELOAD specification. use the whole 128 bits as defined by the RELOAD specification.
11. Security Considerations 11. Security Considerations
The security considerations of RELOAD (Section 12 of The security considerations of RELOAD (Section 12 of
skipping to change at page 8, line 49 skipping to change at page 8, line 47
parameter is used instead of encrypted connections, the HIP header parameter is used instead of encrypted connections, the HIP header
remains visible but the contents are protected. remains visible but the contents are protected.
Limiting the Node ID and Resource ID space into 128 bits (or 100 bits Limiting the Node ID and Resource ID space into 128 bits (or 100 bits
with ORCHID prefixes) results in a higher probability for ID with ORCHID prefixes) results in a higher probability for ID
collisions, both unintentional and intentional, than using larger collisions, both unintentional and intentional, than using larger
address spaces. address spaces.
12. IANA Considerations 12. IANA Considerations
This document has no IANA actions. This section is to be interpreted according to [RFC5226].
IANA is requested to update the "Overlay Link Protocol" registry
[I-D.ietf-p2psip-base] by assigning new Overlay Link Protocol type
"HIP" (see Section 10).
13. Acknowledgements 13. Acknowledgements
Tom Henderson provided valuable comments on the draft. Tom Henderson provided valuable comments on the draft.
14. References 14. References
14.1. Normative References 14.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.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
[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.
[I-D.ietf-hip-bone] [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment", Based Overlay Networking Environment (BONE)", RFC 6079,
draft-ietf-hip-bone-07 (work in progress), June 2010. January 2011.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-12 (work in Base Protocol", draft-ietf-p2psip-base-18 (work in
progress), November 2010. progress), August 2011.
[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.
[RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol
(HIP) Multi-Hop Routing Extension", RFC 6028, (HIP) Multi-Hop Routing Extension", RFC 6028,
October 2010. October 2010.
[I-D.ietf-hip-hiccups] [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-Layer Protocol
Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.
Signaling (HICCUPS)", draft-ietf-hip-hiccups-05 (work in
progress), July 2010.
[I-D.ietf-hip-cert] [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
Certificates", draft-ietf-hip-cert-06 (work in progress),
November 2010. [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the
Host Identity Protocol", RFC 6261, May 2011.
14.2. Informational References 14.2. Informational References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 23 change blocks. 
68 lines changed or deleted 60 lines changed or added

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