Network Working Group D. Thaler
Internet-Draft Microsoft
Expires: September 1, 2010 February 28, 2010
Unique IPv4-Mapped Addresses
draft-thaler-6man-unique-v4mapped-00.txt
Abstract
This document proposes an IPv6 address format for uniquely
identifying IPv4 destinations. Today the IPv4-mapped format, when
used with private IPv4 addresses, does not provide this capability.
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 September 1, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Thaler Expires September 1, 2010 [Page 1]
Internet-Draft Unique IPv4-Mapped Addresses February 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Address Format . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Thaler Expires September 1, 2010 [Page 2]
Internet-Draft Unique IPv4-Mapped Addresses February 2010
1. Introduction
The use of non-global ([RFC1918], [RFC3927]) IPv4 addresses presents
some problems for multihomed nodes, when attached to two networks
using the same address space. Typically, the impact is that
applications can only talk to destinations on one of the two
networks. The issue is that the address alone is ambiguous, and
typical application APIs do not provide a mechanism to distinguish
between them.
In IPv6, non-global addresses were also introduced in the form of
link-local addresses [RFC4291] and unique local addresses [RFC4193]
(as well as site-local addresses, which were deprecated in
[RFC3879]). To resolve the ambiguity, the basic IPv6 APIs were
defined (in [RFC3493]) to include a "scope id" field, where the scope
id is defined as a machine-local identifier for a set of interfaces.
The IPv6 address architecture [RFC4291] also defines an IPv6 address
format known as an IPv4-mapped IPv6 address, for representing the
addresses of IPv4 nodes as IPv6 addresses. These addresses were used
in the basic IPv6 APIs so that host stacks could let applications use
the IPv4 stack under an AF_INET6 socket, by using with addresses in
IPv4-mapped format (for more information see [RFC4038]). As such,
IPv4-mapped addresses also have a scope id in socket APIs, and in
theory this would provide an incentive for applications to use IPv6
APIs even when talking to IPv4-only destinations. However, there are
still several problems with using IPv6 APIs to disambiguate between
IPv4 destinations.
1. [RFC3484] section 3.3 specifies that IPv4-mapped addresses should
be treated as having global scope for purposes of address
selection. As a result, OS's have used a 0 scope id, as with all
global addresses per [RFC4007] section 11.2.
2. [RFC4007] specifies a textual address syntax with an '%'
character to indicate a scope id. However, this character is not
legal in an IPv6 literal within a URI (see [RFC3986] section
3.2.2).
3. Requiring use of a scope id in addition to an address is error
prone and confusing to developers and end users. These issues
are discussed in more detail in [RFC3879] and led to the
deprecation of site-local addresses.
2. Address Format
Unique local addresses [RFC4193] replaced the concept of a machine-
specific scope id value with a 40-bit shared network-specific
identifier that was embedded in the address itself. As a result,
addresses became unambiguous and were usable without requiring a
Thaler Expires September 1, 2010 [Page 3]
Internet-Draft Unique IPv4-Mapped Addresses February 2010
separate scope id.
We propose applying a similar solution for IPv4-mapped addresses.
The proposed format of the "Unique IPv4-mapped IPv6 address" is as
follows:
| 40 bits | 40 bits |16 bits| 32 bits |
+-------------------+-------------+-------+---------------------+
| Well-Known Prefix | Global ID | Comp. | IPv4 address |
+----------------+--+-------------+-------+---------------------+
Well-Known Prefix: The proposed prefix is 0:0:FF00::/40. The use of
a well-known prefix allows hosts and applications to easily detect
this type of address, e.g. to distinguish a native address from one
involving translation. (It is for this reason that a ULA is not used
for this purpose.) This prefix also ensures that the address range
cannot conflict with the IPv4-translatable address range defined in
[RFC2765] section 2.1 (which is ::ffff:0:a.b.c.d).
Global ID: A Global ID as specified in [RFC4193] section 3.2. For
hosts with Unique Local Addresses, the Global ID may be the same
Global ID as used in the IPv6 unique local addresses on the same
network.
Comp.: The 1's complement checksum of the first 80 bits of the
address, to avoid any changes to the transport protocol's pseudo
header checksum.
IPv4 address: The IPv4 address appears in the last 32 bits so that
dotted-decimal format can be used in the textual representation of an
address, as defined in [RFC4291] section 2.2.
3. Security Considerations
As noted in [RFC4007] section 12, requiring the use of a scope id in
addition to an address introduced some security complications. By
making an IPv4-mapped address unique, these addresses become more
usable in security contexts.
4. IANA Considerations
The Well-Known Prefix falls into the range ::/8 reserved by the IETF.
Hence this document has no actions for IANA.
5. References
Thaler Expires September 1, 2010 [Page 4]
Internet-Draft Unique IPv4-Mapped Addresses February 2010
5.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
5.2. Informative References
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
Thaler Expires September 1, 2010 [Page 5]
Internet-Draft Unique IPv4-Mapped Addresses February 2010
Author's Address
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Thaler Expires September 1, 2010 [Page 6]