IETF B. Carpenter
Internet Draft K. Moore
February 1999
Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels
Copyright Notice
Placeholder for ISOC copyright.
Abstract
draft-ietf-ngtrans-6to4-01.txt
This memo specifies an optional mechanism for assigning a unique
IPv6 address prefix to any site that currently has at least one
globally unique IPv4 address, and describes scenarios for using such
a prefix during the co-existence phase of IPv4 to IPv6 transition.
The motivation for this method is to allow isolated IPv6 domains,
attached to an IPv4 network which has no native IPv6 support, to
communicate with other such IPv6 domains with minimal manual
configuration. Effectively it treats the IPv4 network as a virtual
link layer. It also automatically provides a globally unique IPv6
address prefix to any site with at least one globally unique IPv4
address, even if combined with an IPv4 Network Address Translator
(NAT).
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Carpenter + Moore Expires August 1999 [Page 1]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
Table of Contents:
Status of this Memo.............................................1
1. Introduction.................................................3
2. IPv6 Prefix Allocation.......................................3
3. Maximum Transmission Unit....................................4
4. Frame Format.................................................4
5. Multicast and Anycast........................................5
6. Scenarios, scaling, and transition to normal prefixes........5
6.1 Simple scenario - all sites work the same...................5
6.2 Mixed scenario - some sites also have native IPv6...........7
6.3 Multihoming.................................................8
6.4 Transition considerations...................................8
6.5 Usage with firewall or NAT..................................9
6.6 Usage within Intranets......................................9
6.7 Summary of impact on routing................................9
7. ICMP messages...............................................10
8. IANA considerations.........................................10
9. Security considerations.....................................10
Acknowledgements...............................................10
References.....................................................11
Authors' Addresses.............................................11
Intellectual Property..........................................12
Full Copyright Statement.......................................12
Carpenter + Moore Expires August 1999 [Page 2]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
1. Introduction
This memo specifies an optional mechanism for assigning a unique IPv6
address prefix to any site that currently has at least one globally
unique IPv4 address, and describes scenarios for using such a prefix
during the co-existence phase of IPv4 to IPv6 transition. Note that
these scenarios are only part of the total picture of transition to
IPv6, in addition to the mechanisms in [RFC 1933].
The motivation for this method is to allow isolated IPv6 domains,
attached to a wide area network which has no native IPv6 support, to
communicate with other such IPv6 domains with minimal manual
configuration. Effectively it treats the wide area IPv4 network as a
virtual link layer.
IPv6 domains connected using this method do not require IPv4-
compatible IPv6 addresses [RFC 1933] or configured tunnels. In this
way IPv6 gains considerable independence of the underlying wide area
network and can step over many hops of IPv4 subnets. The abbreviated
name of this mechanism is 6to4 (not to be confused with [6OVER4]).
The 6to4 mechanism is implemented almost entirely in boundary
routers, without specfic host modifications except a recommended
address selection algorithm.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. IPv6 Prefix Allocation
Suppose that a subscriber site has at least one valid, globally
unique 32-bit IPv4 address, referred to in this document as V4ADDR.
This address MUST be duly allocated to the site by an address
registry (possibly via a service provider) and it MUST NOT be a
private address [RFC 1918].
The IANA has permanently assigned one 13-bit IPv6 Top Level
Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH,
AGGR], referred to in this document as TLA624. Its numeric value is
0x0010.
[*** temporary note - this assignment remains to be made and may
change ***]
The subscriber site is then deemed to have the following IPv6 address
prefix, without any further assignment procedures being necessary:
Prefix length: 48 bits
Format prefix: 001
TLA value: TLA624
NLA value: V4ADDR
Carpenter + Moore Expires August 1999 [Page 3]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
This is illustrated as follows:
| 3 | 13 | 32 | 16 | 64 bits |
+---+-----+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001| 624 | | | |
+---+-----+-----------+--------+--------------------------------+
Thus, this prefix has exactly the same format as normal prefixes
assigned according to [AGGR]. Within the subscriber site it can be
used for automated address assignment and discovery according to the
normal mechanisms such as [CONF, DISC].
If the subscriber site is not yet running native
IPv6, but is running IPv4 multicast, this "6 to 4" address prefix can
be used in conjunction with the "6 over 4" mechanism [6OVER4]. Thus
isolated IPv6 hosts within isolated IPv6 domains can communicate by
using "6 over 4" to a boundary router and "6 to 4" over the wide
area.
3. Maximum Transmission Unit
If the IPv6 MTU size proves to be too large for some intermediate
IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this
is not necessarily disastrous, unless the fragments are delivered to
different IPv4 destinations due to some form of IPv4 anycast. The
IPv4 "do not fragment" bit MUST NOT be set in the encapsulating IPv4
header.
The default MTU size for IPv6 packets is 1280 octets [IPV6], which is
greater than the specified minimum IPv4 MTU size of 576 octets [RFC
791]. In the event that the IPv6 Path MTU is discovered to be less
than 1280 octets, the 6to4 egress router MUST return an ICMP Packet
Too Big message reporting a Next-Hop MTU less than 1280. The
procedure described in the last paragraph of Section 5 of [IPv6] MUST
then be followed by analogy. Note that this does not require any
modification to an IPv6 host conforming to [IPv6]. Other
considerations are as described in Section 4.1.1 of [RFC 1933].
4. Frame Format
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
protocol type of 41, the same as has been assigned [RFC 1933] for
IPv6 packets that are tunneled inside of IPv4 frames. The IPv4
header contains the Destination and Source IPv4 addresses. One or
both of these will be identical to the V4ADDR field of an IPv6 prefix
formed as specified above (see section 6 for more details). The IPv4
packet body contains the IPv6 header and payload.
Carpenter + Moore Expires August 1999 [Page 4]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
If there are IPv4 options, then padding SHOULD be added to the IPv4
header such that the IPv6 header starts on a boundary that is a 32-
bit offset from the end of the datalink header.
The IPv4 Time to Live will be set as normal [RFC 791], as will the
encapsulated IPv6 hop limit [IPv6]. Other considerations are as
described in Section 4.1.2 of [RFC 1933].
5. Multicast and Anycast
Nothing prevents IPv6 multicast packets being sent to or sourced from
a 6to4 router. A multicast routing protocol such as PIM-SM may be
used. However, since unicast routing for 6to4 has some peculiarities
discusssed in the next section, an IPv6 multicast tree that covers
both 6to4 and non-6to4 sites is likely to have a sub-optimal
topology. If it has a single branch in the 6to4 address space, the
multicast packets are likely to traverse large regions of the IPv4
network as well as corresponding regions of the IPv6 network. If the
tree has multiple branches in the 6to4 address space, 6to4
encapsulation of the same multicast packet will take place multiple
times.
The allocated anycast address space [ANYCAST] is compatible with
TLA624 prefixes.
6. Scenarios, scaling, and transition to normal prefixes
6.1 Simple scenario - all sites work the same
The simplest deployment scenario for 6to4 is for use between a number
of sites, each of which has at least one connection to a shared IPv4
Carpenter + Moore Expires August 1999 [Page 5]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
Internet. This could be the global Internet, or it could be a
corporate IP network. In the case of the global Internet, there is no
requirement that the sites all connect to the same Internet service
provider. The only requiremement is that any of the sites is able to
send IPv4 packets to any of the others.
By definition, each site has an IPv6 prefix in the format defined in
Section 2. It will therefore create DNS records for these addresses.
For example, site A which owns IPv4 address 192.1.2.3 will create DNS
records with the IPv6 prefix {FP=001,TLA=TLA624,NLA=192.1.2.3}/48.
Site B which owns address 9.254.253.252 will create DNS records with
the IPv6 prefix {FP=001,TLA=TLA624,NLA=9.254.253.252}/48.
When an IPv6 host on site B queries the DNS entry for a host on site
A, the DNS returns an address with the prefix
{FP=001,TLA=TLA624,NLA=192.1.2.3}/48 and whatever SLA and Interface
ID applies. The converse applies when a host on site A queries the
DNS for a host on site B. IPv6 packets are formed and transmitted in
the normal way within both sites.
The only change to standard IPv6 routing is that the egress router on
each 6to4 site MUST include the sending rule:
if the destination address of an IPv6 packet is
{FP=001,TLA=TLA624}/16
then
if the NLA field is an IPv4 address assigned to this site
then queue the packet for local IPv6 forwarding
else encapsulate the packet in IPv4 as in Section 3
with destination address set to the NLA value V4ADDR;
queue the packet for IPv4 forwarding.
A simple decapsulation rule for incoming IPv4 packets with protocol
type 41 is also required:
Apply any security checks (see Section 8)
Remove the IPv4 header
Submit the packet to local IPv6 routing.
In this scenario, no IPv4 routing information is imported into IPv6
routing (nor vice versa). The above special sending rule is the only
contamination of IPv6 forwarding, and it occurs only at egress
routers.
In this scenario, any number of 6to4 sites can interoperate with no
prior agreement, no tunnel setup, and no special requirements from
the IPv4 service. All that is required is the appropriate DNS entries
and the special sending rule configured in the egress router. This
router SHOULD also generate the appropriate IPv6 prefix announcements
[CONF, DISC].
It is RECOMMENDED that in any case each site should use only one IPv4
address per egress router, and that should be the address assigned to
the external interface of the egress router. Single-homed sites
therefore SHOULD use only one IPv4 address for 6to4 routing. Multi-
homed sites are discused in section 6.3.
Carpenter + Moore Expires August 1999 [Page 6]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
Because of the lack of setup and prior agreement, and the distributed
deployment model, there are believed to be no particular scaling
issues with the 6to4 mechanism.
6.2 Mixed scenario - some sites also have native IPv6
Suppose one or more of the sites described above acquire native IPv6
connectivity in addition to 6to4 connectivity. In this case it is
necessary to relay packets between the 6to4 realm and the native IPv6
realm. There must be at least one router acting as a relay. There is
nothing special about this; it is simply a normal router which
happens to have at least one logical 6to4 egress interface and at
least one other IPv6 interface.
An IPv6 router willing to act as a relay from native IPv6 to the 6to4
address space advertises a route to {FP=001,TLA=TLA624}/16 into the
native IPv6 routing system, and whatever other native IPv6 prefixes
are appropriate on its 6to4 interface. These prefixes will indicate
the regions of native IPv6 topology that the relay router is willing
to relay to. Their choice is a matter of routing policy. It is
clearly desirable for network operators to carefully consider
desirable traffic patterns and topology when choosing the scope of
such advertisements.
Within a 6to4 site, the {FP=001,TLA=TLA624}/16 prefix will normally
be handled as a default route.
It is a matter of routing policy how far the advertisement of
{FP=001,TLA=TLA624}/16 is propagated. Since there will presumably be
multiple relay routers advertising it, network operators will require
to filter it in a managed way. Incorrect policy in this area will
lead to potential unreachability or to perverse traffic patterns.
A 6to4 site which also has a native IPv6 connection MUST NOT
advertise its TLA624/48 prefix on that connection, and IPv6 network
operators MUST filter out and discard any TLA624 prefix
advertisements longer than /16.
Sites which have at least one native IPv6 egress, in addition to a
6to4 egress, will therefore have at least one IPv6 prefix which is
not a TLA624 prefix. Such sites' DNS entries will reflect this and
DNS lookups will return multiple addresses. If two such sites need
to interoperate, whether the 6to4 route or the native route will be
used depends on IPv6 address selection by the individual hosts (or
even applications).
Now consider again the example of the previous section. Suppose an
IPv6 host on site B queries the DNS entry for a host on site A, and
the DNS returns multiple IPv6 addresses with different prefixes. If
the host picks the 6to4 prefix according to some rule for multiple
prefixes, it will simply send packets to an IPv6 address formed with
the prefix {FP=001,TLA=TLA624,NLA=192.1.2.3}/48. It is essential that
they are sourced from the prefix
Carpenter + Moore Expires August 1999 [Page 7]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
{FP=001,TLA=TLA624,NLA=9.254.253.252}/48 for two-way connectivity to
be possible.
The following algorithm SHOULD be used for address selection. Suppose
that sending host B has a set {B} of IPv6 addresses, and the DNS has
returned a set {A} of IPv6 addresses for host A. Then B performs a
longest prefix match for each address in {B} against each member of
{A}, and selects as the address pair to be used that pair with the
overall longest match. This guarantees that a pair of TLA624
addresses will be selected unless there is a better match using
native IPv6 addresses, which is the desired result. In the case of a
tie the choice is arbitrary. This algorithm is believed to be of
general application as it will always select the topologically
closest pair of addresses. It is the only host software change
required.
6.3 Multihoming
Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by
using a TLA624 prefix for each IPv4 egress router, thereby
automatically obtaining a degree of IPv6 multihoming. The address
selection algorithm of the previous section will apply.
6.4 Transition considerations
If the above rules for routing advertisements and address selection
are followed, then a site can migrate from using 6to4 to using native
IPv6 connections over a long period of co-existence, with no need to
stop 6to4 until it has ceased to be used. The stages involved are
1. Run IPv6 on site using any suitable implementation. True native
IPv6, [6OVER4], or tunnels are all acceptable.
2. Configure an egress router to the external IPv4 network to
support 6to4, including advertising the appropriate TLA624
prefix locally. Configure IPv6 DNS entries using this prefix.
At this point the 6to4 mechanism is automatically available.
3. When native external IPv6 connectivity becomes available,
add a second (native) IPv6 prefix to both the egress router
configuration and the DNS configuration. At this point, the
address selection rule described above will determine when
6to4 and when native IPv6 will be used.
4. When 6to4 usage is determined to have ceased (which may
be several years later), remove the 6to4 configuration.
Carpenter + Moore Expires August 1999 [Page 8]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
6.5 Usage with firewall or NAT
The 6to4 mechanisms can run exactly as described above in the
presence of a firewall at the egress router.
If the site concerned has very limited global IPv4 address space, and
is running an IPv4 network address translator (NAT), all of the above
mechanisms remain valid. The address used for V4ADDR will simply be a
globally unique IPv4 address allocated to the NAT, which will also
function as an IPv6 6to4 router. Combining a 6to4 router with an IPv4
NAT offers the site concerned a globally unique IPv6 /48 prefix,
automatically, behind the IPv4 address of the NAT. Thus every host
behind the NAT can become an IPv6 host with no need for additional
address space allocation, and no intervention by the Internet service
provider. No address translation is needed by these IPv6 hosts.
A more complex situation arises if a host is more than one NAT hop
away from the globally unique IPv4 address space. This document does
not adress this situation.
6.6 Usage within Intranets
There is nothing to stop the above scenario being deployed within a
private corporate network as part of its internal transition to IPv6;
the corporate IPv4 backbone would serve as the virtual link layer for
individual corporate sites using TLA624 prefixes. In this case the
V4ADDR MAY be a private IPv4 address [RFC 1918], which MUST be
unique within the private network. The corresponding DNS record MUST
NOT be advertised outside the private network.
6.7 Summary of impact on routing
IGP (site) routing will treat the local site's TLA624 /48 prefix
exactly like a native IPv6 site prefix assigned to the local site.
There will also be an IGP route to the generic {FP=001,TLA=TLA624}/16
prefix, which will be a route to the site's 6to4 router, unless this
is handled as a default route.
EGP (i.e. BGP) routing will include advertisements for the
{FP=001,TLA=TLA624}/16 prefix from relay routers into the native IPv6
realm, whose scope is limited by routing policy. This is the only
non-native IPv6 prefix advertised by BGP.
It will be necessary for 6to4 routers to obtain routes to relay
routers in order to access the native IPv6 realm. In the simplest
case there will be a manually configured default IPv6 route to
{FP=001,TLA=TLA624,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address
of a relay router. Such a route can be used to establish a BGP
session for the exchange of additional IPv6 routes.
Carpenter + Moore Expires August 1999 [Page 9]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
7. ICMP messages
ICMP "unreachable" and other messages returned by the IPv4 routing
system will be returned to the egress router or relay router that
generated a encapsulated TLA624 packet. However, this router will
often be unable to return an ICMPv6 message to the originating IPv6
node, due to the lack of sufficient information in the "unreachable"
message. This means that the IPv4 network will appear as an
undiagnosable link layer for IPv6 operational purposes. Other
considerations are as described in Section 4.1.3 of [RFC 1933].
8. IANA considerations
No assignments by the IANA are required except the special TLA value
TLA624 = 0x0010. [*** value to be confirmed ***]
9. Security considerations
Implementors should be aware that, in addition to posssible attacks
against IPv6, security attacks against IPv4 must also be considered.
Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant except if traffic
analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the 6to4
domain. Therefore, implementing IPv6 security is required even if
IPv4 security is available.
By default, 6to4 traffic will be accepted and decapsulated from any
source from which regular IPv4 traffic is accepted. If this is for
any reason felt to be a security risk (for example, if IPv6 spoofing
is felt to be more likley than IPv4 spoofing), then additional
source-based packet filtering could be applied. A possible
plausibility check is whether the encapsulating IPv4 address is
consistent with the encapsulated TLA624 address. If this check is
applied, exceptions to it must be configured to admit traffic from
relay routers (Section 6). TLA624 traffic must also be excepted from
checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].
Acknowledgements
The basic idea presented above is probably not original, and we have
had invaluable comments from Jim Bound, Matt Crawford, Richard
Draves, Thomas Narten and other members of the NGTRANS working group.
Some text has been copied from [6OVER4].
Carpenter + Moore Expires August 1999 [Page 10]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
References
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373
[AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374
[CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460
[6OVER4] Carpenter, B., and Jung., C. "Transmission of IPv6 over
IPv4 Domains without Explicit Tunnels", draft-ietf-ipngwg-6over4-
02.txt (work in progress).
[ANYCAST] Johnson, D. and Deering, S., Reserved IPv6 Subnet Anycast
Addresses, draft-ietf-ipngwg-resv-anycast-01.txt (work in progress).
[RFC 791] Postel, J., "Internet Protocol", RFC 791
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
Lear, E., "Address Allocation for Private Internets", RFC 1918
[RFC 1933] Transition Mechanisms for IPv6 Hosts and Routers. R.
Gilligan & E. Nordmark, RFC 1933
[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels.
S. Bradner, RFC 2119
Authors' Addresses
Brian E. Carpenter
IBM United Kingdom Laboratories
MP 185, Hursley Park
Winchester, Hampshire SO21 2JN, UK
Email: brian@hursley.ibm.com
Keith Moore
Innovative Computing Laboratory
University of Tennessee
104 Ayres Hall
Knoxville TN 37996, USA
Email: moore@cs.utk.edu
Carpenter + Moore Expires August 1999 [Page 11]
Internet Draft Connection of IPv6 Domains via IPv4 Clouds Feb 1999
Intellectual Property
PLACEHOLDER for full IETF IPR Statement if needed.
Full Copyright Statement
PLACEHOLDER for full ISOC copyright Statement if needed.
Carpenter + Moore Expires August 1999 [Page 12]
