Internet Draft D. Thaler
October 19, 2006 Microsoft
Expires April 2007
A Comparison of IP Mobility-Related Protocols
<draft-thaler-mobility-comparison-02.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6),
and the Host Identity Protocol (HIP) all address various aspects of
mobility and multi-homing in similar ways. This document gives a
brief comparison of their features.
1. Introduction
This document describes a number of commonalities and differences
between Mobile IPv6 [MIP6], the Level 3 Multihoming Shim Protocol
[SHIM6], and the Host Identity Protocol [HIP]. Each of them
addresses different aspects of the overall mobility and multi-homing
problems. The set of features compared herein was constructed based
on taking the union of the problem statements for each protocol. As
we will see, significant overlap exists, but each has unique aspects
that the others do not address.
Thaler Expires April 2007 1
Draft IP Mobility Comparison October 2006
This comparison shows a snapshot in time, and there may be
additional work not mentioned here which adds capabilities to one or
more of the protocols discussed herein. Only work currently within
the IETF has been considered in the tables below. Finally, only
IPv6 is considered within this document, although some protocols may
work for IPv4 as well.
In this document, three types of identifiers are referred to:
Name: A DNS fully-qualified domain name.
Upper-layer Identifier (ULID): An address used by protocols and
applications above the mobility/multi-homing sub-layer. In MIP6,
this is a Home Address (HoA). SHIM6 uses normal IPv6 addresses
as upper-layer identifiers, and calls them ULIDs when used as
such. In HIP, this is a Host Identity Tag (HIT).
Locator: An address used for routing below the mobility/multi-homing
sub-layer. In MIP6, this is a Care-of Address. SHIM6 and HIP
use normal IPv6 addresses and simply call them Locators.
2. Layering
MIP6, SHIM6, and HIP all insert a conceptual sub-layer between the
routing portion of the network layer, and the transport layer. Each
of them does some processing in the data path for specific headers.
MIP6 uses a Destination Options Header with a Home Address Option in
data packets sent from a home address, and a Type 2 Routing Header
in packets sent to a home address. SHIM6 defines a Payload
Extension Header. HIP uses the Encapsulating Security Payload
header itself. A theoretical packet with all of the above present,
plus other extension headers, would thus look like this:
+------+------+-------+---------+-------+------+-------+----------
| IPv6 | HbH | Type2 | DstOpts | SHIM6 | Frag | ESP | Payload
| Hdr | Opts | RtHdr | (HoA) | PEH | Hdr | (HIP) |
+------+------+-------+---------+-------+------+-------+----------
As can be seen from this, MIP6 headers appear first, followed by
SHIM6, followed by HIP. As such, a natural organization in an
implementation would be (ignoring other destination options):
Thaler Expires August 2006 2
Draft IP Mobility Comparison October 2006
+============================+
| Transport layer |
+============================+
| IPsec + HIP sub-layer | \
+----------------------------+ \
| Fragmentation/reassembly | \
+----------------------------+ \
| SHIM6 sub-layer | Network layer
+----------------------------+ /
| MIP6 sub-layer | /
+----------------------------+ /
| Routing sub-layer | /
+============================+
3. Feature Comparison
The following table summarizes the features compared in this
section. Each line has a corresponding section below with a more
detailed explanation.
+-------------------+--------------+-------------+-----------------+
| | MIP6 | SHIM6 | HIP |
+-------------------+--------------+-------------+-----------------+
| Preserve | | | |
| established | Yes | Yes | Yes |
| connections | | | |
+-------------------+--------------+-------------+-----------------+
| Support both ends | Yes | Only w/in | Yes |
| moving simultan. | | known set | |
+-------------------+--------------+-------------+-----------------+
| Span path outages | No | Yes | No |
| | | | |
+-------------------+--------------+-------------+-----------------+
| Resolve name to | | | |
| locators immed. | Yes | No | Yes |
| after move | | | |
+-------------------+--------------+-------------+-----------------+
| Support referrals | Yes | Yes | Only by name |
+-------------------+--------------+-------------+-----------------+
| Stable addresses | Yes | Assumed | Non-routable |
+-------------------+--------------+-------------+-----------------+
| Support load | Yes | Yes | Yes |
| spreading | (monami6) | | |
+-------------------+--------------+-------------+-----------------+
| Multicast support | Yes | Not mobile | No |
+-------------------+--------------+-------------+-----------------+
3.1. Preserve established connections
All three protocols are able to preserve established connections
across a locator change, including by both sides simultaneously.
Thaler Expires August 2006 3
Draft IP Mobility Comparison October 2006
3.2. Support both ends moving simultan.
MIP6 and HIP both are able to preserve established connections even
if both ends move simultaneously. SHIM6 is only able to do so if at
least one end only moves to a new locator which has previously been
communicated to the other prior to the move.
3.3. Span path outages
A "path outage" here refers to a case where both ends of a
connection believe they have network connectivity and their locator
is valid, but the path between the locator pair is broken somewhere
in the middle of the network.
MIP6 is not able to preserve connections across such outages between
the correspondent node and the home address. HIP would be capable
of preserving connections across such outages, but has no mechanisms
for detecting failures end-to-end and testing alternate paths.
SHIM6 was designed for this scenario and is able to preserve
connections across such outages.
3.4. Resolve name to locators immed. after move
If the TTL in the DNS AAAA records is (say) 30 seconds, or if DNS
resolvers do not respect a TTL less than 30 seconds, then normally
new connections to a device would not be able to be established for
up to 30 seconds after the device moves to a new network location.
MIP6 and HIP are both able to accept new connections without waiting
for name resolution, since DNS records need not be updated when
moving.
SHIM6 does not attempt to address this problem.
3.5. Support referrals
In some applications and protocols, one device redirects another
device to a third device. Such a redirection may be by giving it
the name or the upper-layer identifier of the third party. Another
similar variation occurs when one device wants to connect back to
another device which previously connected to it.
MIP6 and SHIM6 both support such referrals by either name or upper-
layer identifier.
HIP, on the other hand, currently only supports referrals by name,
not upper-layer identifier. This is because there is currently no
way to get the locator corresponding to a HIT, without knowing the
name. As a result, applications and protocols that use address-
based referrals do not work with HIP. The IRTF is currently
investigating addressing this problem via a Distributed Hash Table.
Thaler Expires August 2006 4
Draft IP Mobility Comparison October 2006
3.6. Stable addresses
Many applications and higher-layer protocols today cache addresses
for a significant length of time. Because of this, there is often a
desire for stable (i.e., long-lived) upper-layer identifiers.
Typically this is desired to be able to accept new connections
immediately (section 3.2) and to support referrals (section 3.5).
It is also useful for management purposes.
MIP6 provides this by providing a stable Home Address. SHIM6 does
not attempt to address this problem, nor does it make the problem
any worse. HIP provides a stable upper-layer identifier, but it is
not a routable address.
3.7. Support load spreading
When multiple locators are advertised to another device, that other
device can do load spreading of different connections to the first
device by using different locators.
SHIM6 supports the ability to advertise multiple locators, whereas
MIP6 itself only advertises a single one, but there is work in
progress [MCOA] on extending MIP6 to advertise multiple locators.
HIP also supports the ability to advertise multiple locators, but
its ability to use them is not as mature as SHIM6.
3.8. Multicast support
MIP6 supports sourcing multicast from home addresses by tunneling it
through the home agent. In SHIM6, multicast can be sourced from any
address, but it does not support moving such sessions with SHIM6.
HIP, on the other hand, does not support sourcing multicast from
HITs.
4. Efficiency Considerations
The following table summarizes the efficiency metrics compared in
this section. Each line has a corresponding section below with a
more detailed explanation.
Thaler Expires August 2006 5
Draft IP Mobility Comparison October 2006
+--------------+-------------------+-------------+-----------------+
| | MIP6 | SHIM6 | HIP |
+--------------+-------------------+-------------+-----------------+
| Per-packet | 0 if both home / | 0 normally/ | 0 (beyond IPsec |
| overhead | 20/40 if src away | 8 if moved | transport mode) |
| (bytes) | + 24 if dest away | | |
+--------------+-------------------+-------------+-----------------+
| Connect | 0 | 0 | 0 + 4 for IPsec |
| overhead | | | key negotiation |
| (messages) | | | |
+--------------+-------------------+-------------+-----------------+
| Locator | 2 to update HA | | 3 to update RVS |
| change | + | | + |
| overhead | 6 / 4 (cga) / | 4 to update | 3 to update |
| (messages) | 0 if local (hmip6)| peer | peer |
| | to update peer | | |
+--------------+-------------------+-------------+-----------------+
4.1. Per-packet overhead (bytes)
MIP6 uses a Destination Options Header with a Home Address Option
(20 bytes) in data packets sent from a home address. If packets are
reverse tunneled to a home agent, then there is instead an overhead
of at least 40 bytes (the size of an IPv6 Header), plus any other
extension headers used by the tunnel, if any, on packets between the
mobile node and the home agent
MIP6 uses a Type 2 Routing Header (24 bytes) in packets sent to a
home address. When both ends use home addresses, the overhead is
thus 44 bytes (or if reverse tunneling is used instead, 64 bytes
between the mobile node and the home agent).
If a packet is fragmented, the above overhead is added to every
fragment.
SHIM6 uses an 8-byte Payload Extension Header with data packets. If
a packet is fragment, this overhead is added to every fragment.
This overhead is only present after a locator change occurs.
HIP uses the IP Encapsulating Security Payload (ESP) within data
packets. As such, the overhead is equal to the size of the ESP
header, or 0 if IPsec transport mode would be used anyway.
Furthermore, its processing is per reassembled packet, not per
fragment.
4.2. Connect overhead
At the time data is first exchanged between a mobile node and a
correspondent node (e.g., a TCP connect), MIP6 generates no
additional messages prior to a switch to use route optimization. At
the time a mobile node is away from home and decides to use route
optimization, it generates 6 additional messages (Binding Update,
Thaler Expires August 2006 6
Draft IP Mobility Comparison October 2006
Binding Acknowledgement, Home Test Init, Home Test, Care-of Test
Init, and Care-of Test).
SHIM6 assumes the node is always at home and generates no messages
prior to a locator change.
In HIP, a node is always "away from home" in the sense that its
locator is never equal to the ULID (which is non-routable), and
hence it uses a 4-way handshake to negotiate IPsec state prior to
being able to send data. If IPsec would be used anyway, HIP
requires no additional messages (although whether this is the same,
more, or less overhead than typical IPsec overhead depends on the
key management protocol it is compared to).
4.3. Locator change overhead
To change a locator for existing communication, MIP6 generates 2
messages to update the Home Agent, and 6 (or 4 if the optimization
in [CGA] is used) to update the correspondent node. If the mobile
node is communicating with multiple correspondent nodes, the 2 to
update the Home Agent only applies once, not per correspondent node.
Hierarchical Mobile IPv6 [HMIP6] specifies an optimization which
avoids any messages to correspondent nodes in the case where the
mobile node moves within the same domain; it does so, however, at
the expense of requiring that a Mobility Anchor Point (MAP) is
deployed within that domain and routers are configured to advertise
it.
SHIM6 generates 4 messages to update the peer. HIP generates 3
messages to update the Rendezvous Server (RVS), and a 3 message
handshake to update each peer.
5. Deployment Considerations
The following table summarizes the deployment considerations
compared in this section. Each line has a corresponding section
below with a more detailed explanation.
+-------------------+----------------+-----------+-----------------+
| | MIP6 | SHIM6 | HIP |
+-------------------+----------------+-----------+-----------------+
| One-end benefit | Yes | No | No |
+-------------------+----------------+-----------+-----------------+
| Typical | Home agent, | | Rendezvous Svr, |
| deployment | if hmip used: | None | New RR, IPsec |
| dependencies | MAP + config | | |
| | routers | | |
+-------------------+----------------+-----------+-----------------+
5.1. One-end benefit
Protocols that allow some partial benefit when only one end of a
connection supports the protocol have a deployment advantage over
Thaler Expires August 2006 7
Draft IP Mobility Comparison October 2006
those that require support from both ends. This is because the
former allows a new device to gain immediate benefit, whereas the
latter only gives significant benefit once the majority of devices
it talks to are upgraded.
MIP6 provides benefit for a mobile node even without support in
correspondent nodes; traffic is simply less efficient since traffic
must be routed via the home agent rather than using route
optimization.
SHIM6 and HIP both require support in both ends before their
benefits can be realized.
5.2. Typical deployment dependencies
To gain the full benefits of a protocol, often additional deployment
dependencies exist on other protocols or servers.
MIP6 depends on the existence of a MIP6 Home Agent to be deployed.
As noted in section 4.3, the HMIP6 optimization also requires that a
Mobility Anchor Point be deployed within a domain desiring the
optimization for local movement, and also that routers in that
domain be configured to advertise it.
SHIM6 has no outside dependencies.
HIP depends on the IPsec [IPSEC] protocol for basic operation. It
also depends on the existence of a HIP Rendezvous Server for its
mobility mechanisms. Finally, it requires a new DNS resource
record, and to gain the full security benefit, it depends on the
DNSSec [DNSSEC] protocol. However, the dependency on DNSSec to
secure the name-to-ULID-related information is the same as for the
other protocols, which do not attempt to address the key negotiation
problem.
6. Security Considerations
Security considerations for each protocol discussed herein are
covered in the respective protocol documents. A brief comparison of
their security aspects is listed below.
Thaler Expires August 2006 8
Draft IP Mobility Comparison October 2006
+-------------------+--------------+-------------+-----------------+
| | MIP6 | SHIM6 | HIP |
+-------------------+--------------+-------------+-----------------+
| Control message | | | |
| auth check | | | |
| Minimum | On path | On path + | Cryptographic |
| | | same node | |
| --------+--------------+-------------+-----------------+
| Maximum | Crypto. | Crypto. | Crypto. |
+-------------------+--------------+-------------+-----------------+
| Maximum control | Crypto. | Crypto. | Crypto. |
| msg auth check | | | |
+-------------------+--------------+-------------+-----------------+
| Data security | Optional | Optional | Required |
+-------------------+--------------+-------------+-----------------+
6.1. Control message auth check
Control messages indicating a locator change must be authenticated.
MIP6 and SHIM6 at minimum only verify that control messages were
originated by someone on the path between the two ends. MIP6 at a
mimum only verifies that control messages were originated by someone
on the path between the two ends using a return routability test,
but allows optional cryptographic checks (using what is known as
Cryptographically Generated Addresses (CGAs) [CGA]) for more
security. SHIM6 also uses a return routability test, plus at least
a verification that the new locator is a locator of the same node
(but does not verify that the control message was actually sent by
that node) using a technique known as Hash-Based Addresses; it also
optionally allows CGAs for more security.
HIP, on the other hand, requires strong cryptographic checks on all
control messages.
6.2. Data security
HIP requires that IPsec [IPSEC] be used for data, whereas IPsec is
optional for MIP6 and SHIM6.
7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
Marcelo Bagnulo, Tom Henderson, Vijay Devarapalli, and Hesham
Soliman provided valuable feedback and technical information
regarding this draft.
Thaler Expires August 2006 9
Draft IP Mobility Comparison October 2006
9. Informative References
[CGA] Arkko, J., Vogt, C., and W. Haddad, "Applying
Cryptographically Generated Addresses and Credit-Based
Authorization to Mobile IPv6", Internet Draft, draft-ietf-
mipshop-cga-cba-01.txt, September 2006.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[HIP] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[HMIP6] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[IPSEC] Kent, S. And K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[MCOA] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", Internet Draft, draft-ietf-
monami6-multiplecoa-00.txt, June 2006.
[SHIM6] Nordmark, E. And M. Bagnulo, "Level 3 multihoming shim
protocol", Internet Draft, draft-ietf-shim6-proto-05.txt,
May 2006.
Authors' Addresses
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
Thaler Expires August 2006 10
Draft IP Mobility Comparison October 2006
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.
Thaler Expires August 2006 11