One document matched: draft-van-beijnum-shim6-shim6to4-00.txt
Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: January 7, 2010 July 6, 2009
Shim6 with IPv4 locators through 6to4
draft-van-beijnum-shim6-shim6to4-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/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 January 7, 2010.
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
A limitation of Shim6 is that it only works with IPv6. With 6to4, it
is possible for hosts that only have IPv4 connectivity to still enjoy
Shim6's multihoming benefits.
van Beijnum Expires January 7, 2010 [Page 1]
Internet-Draft Shim6 with 6to4 July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic operation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Possible enhancements . . . . . . . . . . . . . . . . . . . . . 4
3.1. Source address dependent routing . . . . . . . . . . . . . 4
3.2. REAP address pair test order . . . . . . . . . . . . . . . 5
3.3. Tunnel optimization . . . . . . . . . . . . . . . . . . . . 5
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Document and discussion information . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
van Beijnum Expires January 7, 2010 [Page 2]
Internet-Draft Shim6 with 6to4 July 2009
1. Introduction
There are two problems with extending Shim6 ([RFC5533]) to use IPv4.
The first one is that there are insufficient IPv4 addresses to
provide hosts with multiple IPv4 addresses as a matter of course.
The second problem is that the HBA security mechanism [RFC5535] needs
a 64-bit interface identifier, which obviously isn't available with
IPv4.
This document outlines how to use 6to4 tunneling ([RFC3056]) to make
Shim6 available to hosts that only have IPv4 connectivity, or more
generally, that have 6to4 IPv6 connectivity. The use of 6to4
resolves the HBA issue while maintaining the ability for every
locator to be an identifier. Because multiple hosts can share the
6to4 connectivity provided by a single address (per ISP), it also
somewhat addresses the IPv4 address scarcity issue. A downside of
using 6to4 is that hosts must still be able to function as IPv6
hosts; IPv4-only hosts and/or IPv4-only applications can't use Shim6
over 6to4.
6to4 can be useful as a means to provide multihoming for IPv6 hosts
that only have a single non-6to4 IPv6 address, as well as a mechanism
that may be able work around ingress filtering issues in some cases.
2. Basic operation
Basic operation is for a Shim6 host to generate HBA interface
identifiers based on all the available IPv6 addresses, including any
6to4 addresses, and initiate and/or respond to Shim6 negotiations as
per [RFC5533].
If the host has multiple instances of native IPv6 connectivity as
well as 6to4 connectivity, it may either only publish two or more
non-6to4 addresses in the DNS, or publish both types of addresses.
By not publishing 6to4 addresses the situation where hosts that don't
implement [RFC3484] connect across the public 6to4 gateways
unnecessarily is avoided. (This can be from a non-6to4 address to a
6to4 address or the other way around.) The [RFC3484] policy table
ensures that hosts implementing it prefer to connect in the following
order: non-6to4 to non-6to4, 6to4 to 6to4, non-6to4 to 6to4.
(However, IPv4 may be preferred either before or after non-6to4 to
6to4.) On the other hand, by publishing the 6to4 addresses in the
DNS, a client has more opportunities to successfully connect to a
server when there are connectivity problems.
When Shim6 is negotiated, the 6to4 addresses are exchanged as usual,
and when the primary address pair (the "identifiers") stop working,
van Beijnum Expires January 7, 2010 [Page 3]
Internet-Draft Shim6 with 6to4 July 2009
the 6to4 addresses will be tested by the REAP protocol ([RFC5534])
and subsequently used if they work.
3. Possible enhancements
The following enhancements may allow for successful operation in a
larger number of cases, or may improve performance.
3.1. Source address dependent routing
In the situation where a host receives router advertisements
containing different prefixes from different routers, the likelihood
of packets successfully leaving the site can be increased by sending
packets with a source address in the prefix advertised by a certain
router to that router, and not to another router. (Assuming that
both routers are valid default gateways and there are no more
specific routes in the local routing table.)
In the case where two or more routers advertise 6to4 subprefixes
derived from different IPv4 addresses, sending packets towards the
"correct" router has two advantages:
1. If the 6to4 router or a 6to4 gateway performs 6to4 sanity
checking, it may reject packets with 6to4 source addresses that
don't match the IPv4 source address in the outer header of the
packet. With source address dependent routing this situation is
avoided.
2. If one of the routers can't successfully transmit packets, for
instance, because there is a problem in the IPv4 network between
the 6to4 router and the 6to4 gateway or the remote 6to4 router,
using source address dependent routing will select a different
outgoing router when using a different source address. Without
source address dependent routing, the host could use the router
with broken connectivity exclusively and hence be unreachable.
Source address dependent routing is a general purpose mechanism that
can also be helpful with non-6to4 connectivity. It can also be
applied if multiple addresses are configured manually, by matching a
source address to a default gateway address. If multiple DHCPv6-
derived addresses are present on the same interface, prefixes in
router advertisements must be used to correlate the addresses with a
router, as DHCPv6 doesn't provide the information necessary for this.
With DHCPv6 on multiple interfaces the interface provides the
correlation.
If a host performs 6to4 tunneling locally, the source address
van Beijnum Expires January 7, 2010 [Page 4]
Internet-Draft Shim6 with 6to4 July 2009
dependent routing must extend to both the 6to4 tunneling (so that the
IPv4 source address in the outer header matches the 6to4 IPv6 source
address in the inner header) and IPv4 routing. Because IPv4 DHCP
provides both an address and a default gateway address, there is no
issue having multiple DHCP-derived IPv4 addresses on the same
interface with regard to source address dependent routing, although
typically, DHCP clients will not obtain multiple addresses on the
same interface.
3.2. REAP address pair test order
Although specific instances can easily be different, in general
native IPv6 to native IPv6 or native IPv4 to native IPv4 are faster
than native IPv6 to IPv6 tunneled over IPv4. This is especially true
of 6to4, where often public gateways are used that are not
geographically close to either the source or destination. Also, 6to4
packets are filtered or misrouted more often than native IPv6
packets. This problem doesn't exist in the case where the two hosts
communicating both use 6to4. However, in that case, there is
additional encapsulation overhead compared to the native IPv6 case.
As such, the REAP protocol should test address pairs in the following
order:
1. Native IPv6 to native IPv6
2. 6to4 to 6to4
3. Native IPv6 to 6to4 (or the other way around)
3.3. Tunnel optimization
In the future, the Shim6 protocol may be extended to negotiate the
ability to leave out the inner IPv6 header. I.e., only the IPv4
header and the Shim6 context tag would be present in data packets.
However, the implications of such an optimization haven't been
explored at this time.
4. IANA considerations
None.
5. Security considerations
None at this time.
van Beijnum Expires January 7, 2010 [Page 5]
Internet-Draft Shim6 with 6to4 July 2009
6. References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009.
Appendix A. Document and discussion information
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the Shim6 mailinglist or directly to the author.
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain
Email: iljitsch@muada.com
van Beijnum Expires January 7, 2010 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 06:17:19 |