draft-ietf-hip-bone-00.txt   draft-ietf-hip-bone-01.txt 
HIP Working Group G. Camarillo HIP Working Group G. Camarillo
Internet-Draft P. Nikander Internet-Draft P. Nikander
Expires: April 30, 2009 J. Hautakorpi Expires: September 10, 2009 J. Hautakorpi
Ericsson Ericsson
A. Johnston A. Johnston
Avaya Avaya
October 27, 2008 March 9, 2009
HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
Environment Environment
draft-ietf-hip-bone-00.txt draft-ietf-hip-bone-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies a framework to build HIP (Host Identity This document specifies a framework to build HIP (Host Identity
Protocol)-based overlay networks. This framework uses HIP to perform Protocol)-based overlay networks. This framework uses HIP to perform
connection management. Other functions, such as data storage and connection management. Other functions, such as data storage and
retrieval or overlay maintenance, are implemented using protocols retrieval or overlay maintenance, are implemented using protocols
other than HIP. These protocols are loosely referred to as peer other than HIP. These protocols are loosely referred to as peer
protocols. protocols.
skipping to change at page 2, line 26 skipping to change at page 2, line 35
2.3.2. Identifier Assignment and Authentication . . . . . . . 6 2.3.2. Identifier Assignment and Authentication . . . . . . . 6
2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7
2.4. HIP Deployability and Legacy Applications . . . . . . . . 8 2.4. HIP Deployability and Legacy Applications . . . . . . . . 8
3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8 3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8
3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9 3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9
3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10 3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10
3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11 3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11
3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11 3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11
4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12
5. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12 5. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12
5.1. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Peer ID to ORCHID Transformation . . . . . . . . . . . . . 13
5.3. Mapping between Protocol Primitives and HIP Messages . . . 13
6. Architectural Considerations . . . . . . . . . . . . . . . . . 13 6. Architectural Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [I-D.ietf-hip-base] defines a new The Host Identity Protocol (HIP) [RFC5201] defines a new name space
name space between the network and transport layers. HIP provides between the network and transport layers. HIP provides upper layers
upper layers with mobility, multihoming, NAT (Network Address with mobility, multihoming, NAT (Network Address Translation)
Translation) traversal, and security functionality. HIP implements traversal, and security functionality. HIP implements the so called
the so called identifier/locator (ID/locator) split, which implies identifier/locator (ID/locator) split, which implies that IP
that IP addresses are only used as locators, not as host identifiers. addresses are only used as locators, not as host identifiers. This
This split makes HIP a suitable protocol to build overlay networks split makes HIP a suitable protocol to build overlay networks that
that implement identifier-based overlay routing over IP networks, implement identifier-based overlay routing over IP networks, which in
which in turn implement locator-based routing. turn implement locator-based routing.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
provides background information on HIP. Section 3 describes the HIP provides background information on HIP. Section 3 describes the HIP
BONE (HIP-Based Overlay Networking Environment) framework. Section 4 BONE (HIP-Based Overlay Networking Environment) framework. Section 4
discusses some of the advantages derived from using the HIP BONE discusses some of the advantages derived from using the HIP BONE
framework. Section 5 contains the RELOAD-based HIP BONE instance framework. Section 5 contains the RELOAD-based HIP BONE instance
specification. Finally, before the customary sections, Section 6 specification. Finally, before the customary sections, Section 6
attempts to put the presented proposal into a larger architectural attempts to put the presented proposal into a larger architectural
context. context.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
| -------------------------->| | -------------------------->|
| R2 | | R2 |
| <--------------------------| | <--------------------------|
Figure 2: HIP base exchange Figure 2: HIP base exchange
Of course, the initiator needs the responder's locator (or locators) Of course, the initiator needs the responder's locator (or locators)
in order to send its I1 packet. The initiator can obtain locators in order to send its I1 packet. The initiator can obtain locators
for the responder in multiple ways. For example, according to the for the responder in multiple ways. For example, according to the
current HIP specifications the initiator can get the locators current HIP specifications the initiator can get the locators
directly from the DNS [I-D.ietf-hip-dns] or indirectly by sending directly from the DNS [RFC5205] or indirectly by sending packets
packets through a HIP rendezvous server [I-D.ietf-hip-rvs]. However, through a HIP rendezvous server [RFC5204]. However, as an
as an architecture HIP is open ended, and allows the locators to be architecture HIP is open ended, and allows the locators to be
obtained by any means (e.g., from packets traversing an overlay obtained by any means (e.g., from packets traversing an overlay
network or as part of the candidate address collection process in a network or as part of the candidate address collection process in a
NAT traversal scenario). NAT traversal scenario).
2.1.3. Locator Management 2.1.3. Locator Management
Once a HIP connection between two hosts has been established with a Once a HIP connection between two hosts has been established with a
HIP base exchange, the hosts can start exchanging higher-layer HIP base exchange, the hosts can start exchanging higher-layer
traffic. If any of the hosts changes its set of locators, it runs an traffic. If any of the hosts changes its set of locators, it runs an
update exchange [I-D.ietf-hip-mm], which consists of three messages. update exchange [RFC5206], which consists of three messages. If a
If a host is multihomed, it simply provides more than one locator in host is multihomed, it simply provides more than one locator in its
its exchanges. However, if both of the end points move at the same exchanges. However, if both of the end points move at the same time,
time, or through some other reason both lose track of the peers' or through some other reason both lose track of the peers' currently
currently active locators, they need to resort to using a rendezvous active locators, they need to resort to using a rendezvous server or
server or getting new peer locators by some other means. getting new peer locators by some other means.
2.2. NAT Traversal 2.2. NAT Traversal
HIP's NAT traversal mechanism is based on ICE (Interactive HIP's NAT traversal mechanism is based on ICE (Interactive
Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather
address candidates and, as part of the HIP base exchange, hosts address candidates and, as part of the HIP base exchange, hosts
perform an ICE offer/answer exchange where they exchange their perform an ICE offer/answer exchange where they exchange their
respective address candidates. Hosts perform end-to-end STUN respective address candidates. Hosts perform end-to-end STUN
[I-D.ietf-behave-rfc3489bis] based connectivity checks in order to [RFC5389] based connectivity checks in order to discover which
discover which address candidate pairs yield connectivity. address candidate pairs yield connectivity.
Even though, architecturally, HIP lies below the transport layer Even though, architecturally, HIP lies below the transport layer
(i.e., HIP packets are carried directly in IP packets), in presence (i.e., HIP packets are carried directly in IP packets), in presence
of NATs, HIP sometimes needs to be tunneled in a transport protocol of NATs, HIP sometimes needs to be tunneled in a transport protocol
(i.e., HIP packets are carried by a transport protocol such as UDP). (i.e., HIP packets are carried by a transport protocol such as UDP).
2.3. Security 2.3. Security
Security is an essential part of HIP. The following sections Security is an essential part of HIP. The following sections
describe the security-related functionality provided by HIP. describe the security-related functionality provided by HIP.
skipping to change at page 7, line 46 skipping to change at page 7, line 46
However, such considerations go well beyond the current HIP However, such considerations go well beyond the current HIP
architecture and even beyond this proposal. For the purposes of the architecture and even beyond this proposal. For the purposes of the
present document, we merely want to point out that architecturally present document, we merely want to point out that architecturally
HIP supports both self-generated opportunistic identifiers and HIP supports both self-generated opportunistic identifiers and
administratively assigned ones. administratively assigned ones.
2.3.3. Connection Security 2.3.3. Connection Security
Once two nodes complete a base exchange between them, the traffic Once two nodes complete a base exchange between them, the traffic
they exchange is encrypted and integrity protected. The security they exchange is encrypted and integrity protected. The security
mechanism used to protect the traffic is IPsec ESP mechanism used to protect the traffic is IPsec ESP [RFC5202].
[I-D.ietf-hip-esp]. However, there is ongoing work to specify how to However, there is ongoing work to specify how to use different
use different protection mechanisms. protection mechanisms.
2.4. HIP Deployability and Legacy Applications 2.4. HIP Deployability and Legacy Applications
As discussed earlier, HIP defines a native socket API As discussed earlier, HIP defines a native socket API
[I-D.ietf-hip-native-api] that applications can use to establish and [I-D.ietf-hip-native-api] that applications can use to establish and
manage connections. New applications can implement this API to get manage connections. New applications can implement this API to get
full advantage of HIP. However, in most cases, legacy (i.e., non-HIP full advantage of HIP. However, in most cases, legacy (i.e., non-HIP
aware) applications [I-D.ietf-hip-applications] can use HIP through aware) applications [RFC5338] can use HIP through the traditional
the traditional IPv4 and IPv6 socket APIs. IPv4 and IPv6 socket APIs.
The idea is that when a legacy IPv6 application tries and obtains a The idea is that when a legacy IPv6 application tries and obtains a
remote host's IP address (e.g., by querying the DNS) the DNS resolver remote host's IP address (e.g., by querying the DNS) the DNS resolver
passes the remote host's ORCHID (which was also stored in the DNS) to passes the remote host's ORCHID (which was also stored in the DNS) to
the legacy application. At the same time, the DNS resolver stores the legacy application. At the same time, the DNS resolver stores
stores the remote host's IP address internally at the HIP module. stores the remote host's IP address internally at the HIP module.
Since the ORCHID looks like an IPv6 address, the legacy application Since the ORCHID looks like an IPv6 address, the legacy application
treats it as such. It opens a connection (e.g., TCP) using the treats it as such. It opens a connection (e.g., TCP) using the
traditional IPv6 socket API. The HIP module running in the same host traditional IPv6 socket API. The HIP module running in the same host
as the legacy application intercepts this call somehow (e.g., using as the legacy application intercepts this call somehow (e.g., using
skipping to change at page 10, line 39 skipping to change at page 10, line 39
the nodes in its forwarding table. Nodes also need to establish the nodes in its forwarding table. Nodes also need to establish
connections with other nodes in order to exchange application-layer connections with other nodes in order to exchange application-layer
messages. messages.
As discussed earlier, HIP uses the base exchange to establish As discussed earlier, HIP uses the base exchange to establish
connections. A HIP endpoint (the initiator) initiates a HIP base connections. A HIP endpoint (the initiator) initiates a HIP base
exchange with a remote endpoint by sending an I1 packet. The exchange with a remote endpoint by sending an I1 packet. The
initiator sends the I1 packet to the remote endpoint's locator. initiator sends the I1 packet to the remote endpoint's locator.
Initiators that do not have any locator for the remote endpoint need Initiators that do not have any locator for the remote endpoint need
to use a rendezvous service. Traditionally, a HIP rendezvous server to use a rendezvous service. Traditionally, a HIP rendezvous server
[I-D.ietf-hip-rvs] has provided such a rendezvous service. In HIP [RFC5204] has provided such a rendezvous service. In HIP BONE, the
BONE, the overlay itself provides the rendezvous service. overlay itself provides the rendezvous service.
Therefore, in HIP BONE, a node uses an I1 packet (as usual) to Therefore, in HIP BONE, a node uses an I1 packet (as usual) to
establish a connection with another node in the overlay. Nodes in establish a connection with another node in the overlay. Nodes in
the overlay forward I1 packets in a hop-by-hop fashion according to the overlay forward I1 packets in a hop-by-hop fashion according to
the overlay's routing table towards its destination. This way, the the overlay's routing table towards its destination. This way, the
overlay provides a rendezvous service between the nodes establishing overlay provides a rendezvous service between the nodes establishing
the connection. If the overlay nodes have active connections with the connection. If the overlay nodes have active connections with
other nodes in their forwarding tables and if those connections are other nodes in their forwarding tables and if those connections are
protected (typically with IPsec ESP), I1 packets may be sent over protected (typically with IPsec ESP), I1 packets may be sent over
protected connections between nodes. Alternatively, if there no such protected connections between nodes. Alternatively, if there no such
skipping to change at page 12, line 21 skipping to change at page 12, line 21
o bootstrap function o bootstrap function
o how to select STUN and TURN servers for the candidate address o how to select STUN and TURN servers for the candidate address
collection process in NAT traversal scenarios. collection process in NAT traversal scenarios.
o for what type of traffic or messages it is appropriate to use o for what type of traffic or messages it is appropriate to use
lightweight message exchanges. lightweight message exchanges.
Note that the border between HIP BONE instance specification and a Note that the border between HIP BONE instance specification and a
peer protocol specifications is blurry. Depending on how generic the peer protocol specifications is blurry. Depending on how generic the
specification of a given peer protocol is, its associated HIP BONE specification of a given peer protocol is, its associated HIP BONE
instance specification may need to specify more or less details. instance specification may need to specify more or less details.
Also, a particular HIP BONE instance specification left certain areas
unspecified in order to leave their configuration up to each
particular overlays.
4. Advantages of Using HIP BONE 4. Advantages of Using HIP BONE
Using HIP BONE, as opposed to a peer protocol, to perform connection Using HIP BONE, as opposed to a peer protocol, to perform connection
management in an overlay has a set of advantages. HIP BONE can be management in an overlay has a set of advantages. HIP BONE can be
used by any peer protocol. This keeps each peer protocol from used by any peer protocol. This keeps each peer protocol from
defining primitives needed for connection management (e.g., defining primitives needed for connection management (e.g.,
primitives to establish connections and to tunnel messages through primitives to establish connections and to tunnel messages through
the overlay) and NAT traversal. Having this functionality at a lower the overlay) and NAT traversal. Having this functionality at a lower
layer allows multiple upper-layer protocols to take advantage of it. layer allows multiple upper-layer protocols to take advantage of it.
Additionally, having a solution that integrates mobility and Additionally, having a solution that integrates mobility and
multihoming is useful in many scenarios. Peer protocols do not multihoming is useful in many scenarios. Peer protocols do not
typically specify mobility and multihoming solutions. Combining a typically specify mobility and multihoming solutions. Combining a
peer protocol including NAT traversal with a separate mobility peer protocol including NAT traversal with a separate mobility
mechanism and a separate multihoming mechanism can easily lead to mechanism and a separate multihoming mechanism can easily lead to
unexpected (and unpleasant) interactions. unexpected (and unpleasant) interactions.
5. RELOAD-based HIP BONE Instance Specification 5. RELOAD-based HIP BONE Instance Specification
Editor's note: To be done when details about RELOAD are more stable. This section specifies the RELOAD-based HIP BONE instance
specification.
OPEN ISSUES: 5.1. Peer Protocol
o RELOAD uses 128-bit identifiers. Which identifiers should HIP The peer protocol to be used is RELOAD, which is specified in
use? [I-D.ietf-p2psip-base].
o How does a HIP entity know which overlay an incoming I1 belongs
to? 5.2. Peer ID to ORCHID Transformation
o The RELOAD forwarding header carries Via and Destination lists.
What to use as the destination HIT? Final destination (Via and RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit
Destination list functionality in HIP) or next hop? In any case, ORCHIDs, a peer's RELOAD Node-ID is used as the peer's ORCHID.
intermediaries will need to process the messages to process those
lists. 5.3. Mapping between Protocol Primitives and HIP Messages
The Attach procedure in RELOAD establishes a connection between two
peers. This procedure is performed using the AttachReq and AttachAns
messages. When HIP is used, the Attach procedure is performed by
using a HIP base exchange. That is, peers send HIP I1 messages
instead of RELOAD AttachReq messages.
The RELOAD AttachLite procedure is used for the same purpose as the
Attach procedure in scenarios with no NATs. When HIP is used, the
AttachLite procedure is also performed by using a HIP base exchange.
That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq
messages.
OPEN ISSUE: The RELOAD forwarding header carries Via and Destination
lists. We should have the same functionality in HIP so that I1s can
be source routed and R1s can use symmetric routing. The destination
HIT for the I1 packet would be the destination peer. The header
fields defined in RFC 5204 (RVS) and in the NAT traversal draft can
be used to implement that functionality or as templates to specify
new header fields that implement that functionality.
OPEN ISSUE: RELOAD mandates TLS. That is, it does not support plain
TCP or UDP. If HIP is used like this, there will be double
encryption (avoidable using a null encryption algorithm at one of the
levels) and double authentication.
6. Architectural Considerations 6. Architectural Considerations
Architecturally, HIP can be considered to create a new thin "waist" Architecturally, HIP can be considered to create a new thin "waist"
layer on the top of the IPv4 and IPv6 networks; see Figure 3. The layer on the top of the IPv4 and IPv6 networks; see Figure 3. The
HIP layer itself consist of the HIP signalling protocol and one or HIP layer itself consist of the HIP signalling protocol and one or
more data transport protocols; see Figure 4. The HIP signalling more data transport protocols; see Figure 4. The HIP signalling
packets and the data transport packets can take different routes. In packets and the data transport packets can take different routes. In
the HIP BONE, the HIP signalling packets are typically first routed the HIP BONE, the HIP signalling packets are typically first routed
through the overlay and then directly (if possible), while the data through the overlay and then directly (if possible), while the data
skipping to change at page 15, line 40 skipping to change at page 16, line 23
9. IANA Considerations 9. IANA Considerations
This document does not contain any IANA actions. This document does not contain any IANA actions.
10. Normative References 10. Normative References
[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.
[I-D.ietf-hip-base] [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
"Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007. [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338,
September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[I-D.ietf-hip-native-api] [I-D.ietf-hip-native-api]
Komu, M. and T. Henderson, "Basic Socket Interface Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for Host Identity Protocol (HIP)", Extensions for Host Identity Protocol (HIP)",
draft-ietf-hip-native-api-05 (work in progress), draft-ietf-hip-native-api-05 (work in progress),
July 2008. July 2008.
[I-D.ietf-hip-dns] [I-D.nikander-hip-hiccups]
Nikander, P. and J. Laganier, "Host Identity Protocol Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
(HIP) Domain Name System (DNS) Extensions", Identity Protocol) Immediate Carriage and Conveyance of
draft-ietf-hip-dns-09 (work in progress), April 2007. Upper- layer Protocol Signaling (HICCUPS)",
draft-nikander-hip-hiccups-01 (work in progress),
[I-D.ietf-hip-rvs] November 2008.
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006.
[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007.
[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.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-p2psip-base]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
"Session Traversal Utilities for (NAT) (STUN)", H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
draft-ietf-behave-rfc3489bis-18 (work in progress), Base Protocol", draft-ietf-p2psip-base-02 (work in
July 2008. progress), March 2009.
[I-D.ietf-hip-esp]
Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-06 (work in progress), June 2007.
[I-D.ietf-hip-applications]
Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications",
draft-ietf-hip-applications-04 (work in progress),
July 2008.
[I-D.nikander-hip-hiccups]
Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
Identity Protocol) Immediate Carriage and Conveyance of
Upper- layer Protocol Signalling (HICCUPS)",
draft-nikander-hip-hiccups-00 (work in progress),
July 2008.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
skipping to change at page 18, line 4 skipping to change at line 786
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com Email: Jani.Hautakorpi@ericsson.com
Alan Johnston Alan Johnston
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan@sipstation.com Email: alan@sipstation.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 23 change blocks. 
90 lines changed or deleted 126 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/