draft-ietf-hip-multihoming-03.txt   draft-ietf-hip-multihoming-04.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft The Boeing Company Internet-Draft University of Washington
Intended status: Standards Track C. Vogt Intended status: Standards Track C. Vogt
Expires: January 16, 2014 J. Arkko Expires: May 16, 2015 J. Arkko
Ericsson Research NomadicLab Ericsson Research NomadicLab
July 15, 2013 November 12, 2014
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-03 draft-ietf-hip-multihoming-04
Abstract Abstract
This document defines host multihoming extensions to the Host This document defines host multihoming extensions to the Host
Identity Protocol (HIP), by leveraging protocol components defined Identity Protocol (HIP), by leveraging protocol components defined
for host mobility. for host mobility.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 16, 2014. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.2. Multihoming Overview . . . . . . . . . . . . . . . . . . . 7 3.2. Multihoming Overview . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . . 8 4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 8
4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 9 4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9
4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 10 4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 10
4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 10 4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 10
4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 11 4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 11
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 12
5.1. Address Verification . . . . . . . . . . . . . . . . . . . 12 5.1. Address Verification . . . . . . . . . . . . . . . . . . 12
5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 12 5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 12
5.3. Interaction with Security Associations . . . . . . . . . . 13 5.3. Interaction with Security Associations . . . . . . . . . 13
6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 15 6.1. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . 15
6.2. Handling Received LOCATORs . . . . . . . . . . . . . . . . 17 6.2. Handling Received LOCATORs . . . . . . . . . . . . . . . 17
6.3. Verifying Address Reachability . . . . . . . . . . . . . . 19 6.3. Verifying Address Reachability . . . . . . . . . . . . . 19
6.4. Changing the Preferred Locator . . . . . . . . . . . . . . 19 6.4. Changing the Preferred Locator . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative references . . . . . . . . . . . . . . . . . . . 20 10.1. Normative references . . . . . . . . . . . . . . . . . . 20
10.2. Informative references . . . . . . . . . . . . . . . . . . 21 10.2. Informative references . . . . . . . . . . . . . . . . . 21
Appendix A. Document Revision History . . . . . . . . . . . . . . 21 Appendix A. Document Revision History . . . . . . . . . . . . . 22
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [RFC4423] (HIP) supports an architecture The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports
that decouples the transport layer (TCP, UDP, etc.) from the an architecture that decouples the transport layer (TCP, UDP, etc.)
internetworking layer (IPv4 and IPv6) by using public/private key from the internetworking layer (IPv4 and IPv6) by using public/
pairs, instead of IP addresses, as host identities. When a host uses private key pairs, instead of IP addresses, as host identities. When
HIP, the overlying protocol sublayers (e.g., transport layer sockets a host uses HIP, the overlying protocol sublayers (e.g., transport
and Encapsulating Security Payload (ESP) Security Associations (SAs)) layer sockets and Encapsulating Security Payload (ESP) Security
are instead bound to representations of these host identities, and Associations (SAs)) are instead bound to representations of these
the IP addresses are only used for packet forwarding. However, each host identities, and the IP addresses are only used for packet
host must also know at least one IP address at which its peers are forwarding. However, each host must also know at least one IP
reachable. Initially, these IP addresses are the ones used during address at which its peers are reachable. Initially, these IP
the HIP base exchange [RFC5201]. addresses are the ones used during the HIP base exchange
[I-D.ietf-hip-rfc5201-bis].
One consequence of such a decoupling is that new solutions to One consequence of such a decoupling is that new solutions to
network-layer mobility and host multihoming are possible. Host network-layer mobility and host multihoming are possible. Host
mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case
in which a host has a single address and changes its network point- in which a host has a single address and changes its network point-
of-attachment while desiring to preserve the HIP-enabled security of-attachment while desiring to preserve the HIP-enabled security
association. Host multihoming is somewhat of a dual case to host association. Host multihoming is somewhat of a dual case to host
mobility, in that a host may simultaneously have more than one mobility, in that a host may simultaneously have more than one
network point-of-attachment. There are potentially many variations network point-of-attachment. There are potentially many variations
of host multihoming possible. The scope of this document encompasses of host multihoming possible. The scope of this document encompasses
skipping to change at page 3, line 40 skipping to change at page 3, line 34
Another variation of multihoming that has been heavily studied site Another variation of multihoming that has been heavily studied site
multihoming. Solutions for site multihoming in IPv6 networks have multihoming. Solutions for site multihoming in IPv6 networks have
been specified by the IETF shim6 working group. The shim6 protocol been specified by the IETF shim6 working group. The shim6 protocol
[RFC5533] bears many architectural similarities to HIP but there are [RFC5533] bears many architectural similarities to HIP but there are
differences in the security model and in the protocol. Future differences in the security model and in the protocol. Future
versions of this draft will summarize the differences more versions of this draft will summarize the differences more
completely. completely.
While HIP can potentially be used with transports other than the ESP While HIP can potentially be used with transports other than the ESP
transport format [RFC5202], this document largely assumes the use of transport format [I-D.ietf-hip-rfc5202-bis], this document largely
ESP and leaves other transport formats for further study. assumes the use of ESP and leaves other transport formats for further
study.
There are a number of situations where the simple end-to-end There are a number of situations where the simple end-to-end
readdressing functionality defined herein is not sufficient. These readdressing functionality defined herein is not sufficient. These
include the initial reachability of a multihomed host, location include the initial reachability of a multihomed host, location
privacy, simultaneous mobility of both hosts, and some modes of NAT privacy, simultaneous mobility of both hosts, and some modes of NAT
traversal. In these situations, there is a need for some helper traversal. In these situations, there is a need for some helper
functionality in the network, such as a HIP rendezvous server functionality in the network, such as a HIP rendezvous server
[RFC5204]. Such functionality is out of the scope of this document. [I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope
Finally, making underlying IP multihoming transparent to the of this document. Finally, making underlying IP multihoming
transport layer has implications on the proper response of transport transparent to the transport layer has implications on the proper
congestion control, path MTU selection, and Quality of Service (QoS). response of transport congestion control, path MTU selection, and
Quality of Service (QoS). Transport-layer mobility triggers, and the
Transport-layer mobility triggers, and the proper transport response proper transport response to a HIP multihoming address change, are
to a HIP multihoming address change, are outside the scope of this outside the scope of this document.
document.
2. Terminology and Conventions 2. Terminology and Conventions
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].
Terminology is copied from [I-D.ietf-hip-rfc5206-bis]. Terminology is copied from [I-D.ietf-hip-rfc5206-bis].
LOCATOR. The name of a HIP parameter containing zero or more Locator LOCATOR. The name of a HIP parameter containing zero or more Locator
skipping to change at page 5, line 7 skipping to change at page 5, line 7
This section is an overview; more detailed specification follows this This section is an overview; more detailed specification follows this
section. section.
The overall protocol model is the same as in Section 3 of The overall protocol model is the same as in Section 3 of
[I-D.ietf-hip-rfc5206-bis]; this section only highlights the [I-D.ietf-hip-rfc5206-bis]; this section only highlights the
differences. differences.
3.1. Operating Environment 3.1. Operating Environment
The Host Identity Protocol (HIP) [RFC5201] is a key establishment and The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key
parameter negotiation protocol. Its primary applications are for establishment and parameter negotiation protocol. Its primary
authenticating host messages based on host identities, and applications are for authenticating host messages based on host
establishing security associations (SAs) for the ESP transport format identities, and establishing security associations (SAs) for the ESP
[RFC5202] and possibly other protocols in the future. transport format [I-D.ietf-hip-rfc5202-bis] and possibly other
protocols in the future.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | Key | | HIP | | Key | | | | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | | | | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | | | | Process | | | | Process | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| ^ | | ^ | | ^ | | ^ |
| | | | | | | | | | | |
skipping to change at page 6, line 21 skipping to change at page 6, line 21
| --------- | ---------
| | | |
---- --------- ---- ---------
| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
---- --------- ---- ---------
| |
--------- ---------
| IP | | IP |
--------- ---------
Figure 2: Architecture for HIP Multihoming (MH) Figure 2: Architecture for HIP Multihoming (MH)
Figure 2 depicts a layered architectural view of a HIP-enabled stack Figure 2 depicts a layered architectural view of a HIP-enabled stack
using the ESP transport format. In HIP, upper-layer protocols using the ESP transport format. In HIP, upper-layer protocols
(including TCP and ESP in this figure) are bound to Host Identity (including TCP and ESP in this figure) are bound to Host Identity
Tags (HITs) and not IP addresses. The HIP sublayer is responsible Tags (HITs) and not IP addresses. The HIP sublayer is responsible
for maintaining the binding between HITs and IP addresses. The SPI for maintaining the binding between HITs and IP addresses. The SPI
is used to associate an incoming packet with the right HITs. The is used to associate an incoming packet with the right HITs. The
block labeled "MH" is introduced below. block labeled "MH" is introduced below.
Consider the case when a host is multihomed (has more than one Consider the case when a host is multihomed (has more than one
skipping to change at page 7, line 28 skipping to change at page 7, line 28
such as which locators to choose when more than one pair is such as which locators to choose when more than one pair is
available, the operation of simultaneous mobility and multihoming, available, the operation of simultaneous mobility and multihoming,
source address selection policies (beyond those specified in source address selection policies (beyond those specified in
[RFC3484]), and the implications of multihoming on transport [RFC3484]), and the implications of multihoming on transport
protocols and ESP anti-replay windows. protocols and ESP anti-replay windows.
4. Protocol Overview 4. Protocol Overview
In this section, we briefly introduce a number of usage scenarios for In this section, we briefly introduce a number of usage scenarios for
HIP multihoming. These scenarios assume that HIP is being used with HIP multihoming. These scenarios assume that HIP is being used with
the ESP transform [RFC5202], although other scenarios may be defined the ESP transform [I-D.ietf-hip-rfc5202-bis], although other
in the future. To understand these usage scenarios, the reader scenarios may be defined in the future. To understand these usage
should be at least minimally familiar with the HIP protocol scenarios, the reader should be at least minimally familiar with the
specification [RFC5201]. However, for the (relatively) uninitiated HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for
reader, it is most important to keep in mind that in HIP the actual the (relatively) uninitiated reader, it is most important to keep in
payload traffic is protected with ESP, and that the ESP SPI acts as mind that in HIP the actual payload traffic is protected with ESP,
an index to the right host-to-host context. and that the ESP SPI acts as an index to the right host-to-host
context.
The scenarios below assume that the two hosts have completed a single The scenarios below assume that the two hosts have completed a single
HIP base exchange with each other. Both of the hosts therefore have HIP base exchange with each other. Both of the hosts therefore have
one incoming and one outgoing SA. Further, each SA uses the same one incoming and one outgoing SA. Further, each SA uses the same
pair of IP addresses, which are the ones used in the base exchange. pair of IP addresses, which are the ones used in the base exchange.
The readdressing protocol is an asymmetric protocol where a mobile or The readdressing protocol is an asymmetric protocol where a mobile or
multihomed host informs a peer host about changes of IP addresses on multihomed host informs a peer host about changes of IP addresses on
affected SPIs. The readdressing exchange is designed to be affected SPIs. The readdressing exchange is designed to be
piggybacked on existing HIP exchanges. The majority of the packets piggybacked on existing HIP exchanges. The majority of the packets
skipping to change at page 12, line 22 skipping to change at page 12, line 22
<----------------------------------- <-----------------------------------
(process normally) (process normally)
Figure 6: LOCATOR Inclusion in I2 Figure 6: LOCATOR Inclusion in I2
The I1 and I2 may be arriving from different source addresses if the The I1 and I2 may be arriving from different source addresses if the
LOCATOR parameter is present in R1. In this case, implementations LOCATOR parameter is present in R1. In this case, implementations
simultaneously using multiple pre-created R1s, indexed by Initiator simultaneously using multiple pre-created R1s, indexed by Initiator
IP addresses, may inadvertently fail the puzzle solution of I2 IP addresses, may inadvertently fail the puzzle solution of I2
packets due to a perceived puzzle mismatch. See, for instance, the packets due to a perceived puzzle mismatch. See, for instance, the
example in Appendix A of [RFC5201]. As a solution, the Responder's example in Appendix A of [I-D.ietf-hip-rfc5201-bis]. As a solution,
puzzle indexing mechanism must be flexible enough to accommodate the the Responder's puzzle indexing mechanism must be flexible enough to
situation when R1 includes a LOCATOR parameter. accommodate the situation when R1 includes a LOCATOR parameter.
5. Other Considerations 5. Other Considerations
5.1. Address Verification 5.1. Address Verification
An address verification method is specified in An address verification method is specified in
[I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in [I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in
multihoming scenarios also are subject to the same verification multihoming scenarios also are subject to the same verification
rules. rules.
skipping to change at page 13, line 15 skipping to change at page 13, line 15
5.3. Interaction with Security Associations 5.3. Interaction with Security Associations
This document uses the HIP LOCATOR protocol parameter, specified in This document uses the HIP LOCATOR protocol parameter, specified in
[I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange [I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange
information about their locator(s) and any changes in their information about their locator(s) and any changes in their
locator(s). The logical structure created with LOCATOR parameters locator(s). The logical structure created with LOCATOR parameters
has three levels: hosts, Security Associations (SAs) indexed by has three levels: hosts, Security Associations (SAs) indexed by
Security Parameter Indices (SPIs), and addresses. Security Parameter Indices (SPIs), and addresses.
The relation between these levels for an association constructed as The relation between these levels for an association constructed as
defined in the base specification [RFC5201] and ESP transform defined in the base specification [I-D.ietf-hip-rfc5201-bis] and ESP
[RFC5202] is illustrated in Figure 7. transform [I-D.ietf-hip-rfc5202-bis] is illustrated in Figure 7.
-<- SPI1a -- -- SPI2a ->- -<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2 host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<- ->- SPI2a -- -- SPI1a -<-
Figure 7: Relation between Hosts, SPIs, and Addresses (Base Figure 7: Relation between Hosts, SPIs, and Addresses (Base
Specification) Specification)
In Figure 7, host1 and host2 negotiate two unidirectional SAs, and In Figure 7, host1 and host2 negotiate two unidirectional SAs, and
each host selects the SPI value for its inbound SA. The addresses each host selects the SPI value for its inbound SA. The addresses
skipping to change at page 20, line 35 skipping to change at page 20, line 37
of the security section, and Petri Jokela was a co-author of the of the security section, and Petri Jokela was a co-author of the
initial individual submission. initial individual submission.
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan
Melen for many improvements to the document. Melen for many improvements to the document.
10. References 10. References
10.1. Normative references 10.1. Normative references
[I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, [I-D.ietf-hip-rfc5201-bis]
"Host Mobility with the Host Identity Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
Protocol", draft-ietf-hip-rfc5206-bis-06 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
(work in progress), July 2013. hip-rfc5201-bis-14 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC3484] Draves, R., "Default Address Selection [I-D.ietf-hip-rfc5202-bis]
for Internet Protocol version 6 (IPv6)", Jokela, P., Moskowitz, R., and J. Melen, "Using the
RFC 3484, February 2003. Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-05 (work in progress), November 2013.
[RFC4303] Kent, S., "IP Encapsulating Security [I-D.ietf-hip-rfc5206-bis]
Payload (ESP)", RFC 4303, December 2005. Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), July 2013.
[RFC4423] Moskowitz, R. and P. Nikander, "Host [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Identity Protocol (HIP) Architecture", Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 4423, May 2006.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., [RFC3484] Draves, R., "Default Address Selection for Internet
and T. Henderson, "Host Identity Protocol version 6 (IPv6)", RFC 3484, February 2003.
Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
Nikander, "Using the Encapsulating 4303, December 2005.
Security Payload (ESP) Transport Format
with the Host Identity Protocol (HIP)",
RFC 5202, April 2008.
10.2. Informative references 10.2. Informative references
[RFC5204] Laganier, J. and L. Eggert, "Host [I-D.ietf-hip-rfc4423-bis]
Identity Protocol (HIP) Rendezvous Moskowitz, R. and M. Komu, "Host Identity Protocol
Extension", RFC 5204, April 2008. Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
progress), April 2014.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: [I-D.ietf-hip-rfc5204-bis]
Level 3 Multihoming Shim Protocol for Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
IPv6", RFC 5533, June 2009. Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work
in progress), June 2014.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
Appendix A. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| draft-00 | Initial version with multihoming text imported from | | draft-00 | Initial version with multihoming text imported from |
| | RFC5206. | | | RFC5206. |
| | |
| draft-01 | Document refresh; no other changes. | | draft-01 | Document refresh; no other changes. |
| | |
| draft-02 | Document refresh; no other changes. | | draft-02 | Document refresh; no other changes. |
| | |
| draft-03 | Document refresh; no other changes. | | draft-03 | Document refresh; no other changes. |
| | |
| draft-04 | Document refresh; no other changes. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
The Boeing Company University of Washington
P.O. Box 3707 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
EMail: thomas.r.henderson@boeing.com EMail: tomhend@u.washington.edu
Christian Vogt Christian Vogt
Ericsson Research NomadicLab Ericsson Research NomadicLab
Hirsalantie 11 Hirsalantie 11
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone:
EMail: christian.vogt@ericsson.com EMail: christian.vogt@ericsson.com
Jari Arkko Jari Arkko
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 40 5079256 Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
 End of changes. 30 change blocks. 
106 lines changed or deleted 114 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/