As per Relevance of the word mechanism, we have this rfc below:
Network Working Group B.
Request for Comments: 3056 K.
Category: Standards Track February 2001
Connection of IPv6 Domains via IPv4
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo specifies an optional interim mechanism for IPv6 sites
communicate with each other over the IPv4 network without
tunnel setup, and for them to communicate with native IPv6
via relay routers. Effectively it treats the wide area IPv4
as a unicast point-to-point link layer. The mechanism is intended
a start-up transition tool used during the period of co-existence
IPv4 and IPv6. It is not intended as a permanent solution
The document defines a method for assigning an interim unique IPv
address prefix to any site that currently has at least one
unique IPv4 address, and specifies an encapsulation mechanism
transmitting IPv6 packets using such a prefix over the global IPv
network
The motivation for this method is to allow isolated IPv6 domains
hosts, attached to an IPv4 network which has no native IPv6 support
to communicate with other such IPv6 domains or hosts with
manual configuration, before they can obtain natuve IPv
connectivity. It incidentally provides an interim globally
IPv6 address prefix to any site with at least one globally
IPv4 address, even if combined with an IPv4 Network
Translator (NAT).
Carpenter & Moore Standards Track [Page 1]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Table of
1. Introduction................................................. 2
1.1. Terminology................................................ 4
2. IPv6 Prefix Allocation....................................... 5
2.1 Address Selection........................................... 6
3. Encapsulation in IPv4........................................ 6
3.1. Link-Local Address and NUD................................. 7
4. Maximum Transmission Unit.................................... 7
5. Unicast scenarios, scaling, and transition to normal prefixes 8
5.1 Simple scenario - all sites work the same................... 8
5.2 Mixed scenario with relay to native IPv6................... 9
5.2.1 Variant scenario with ISP relay.......................... 12
5.2.2 Summary of relay router configuration.................... 12
5.2.2.1. BGP4+ not used........................................ 12
5.2.2.2. BGP4+ used............................................ 12
5.2.2.3. Relay router scaling.................................. 13
5.2.3 Unwilling to relay....................................... 13
5.3 Sending and decapsulation rules............................ 13
5.4 Variant scenario with tunnel to IPv6 space................. 14
5.5 Fragmented Scenarios....................................... 14
5.6 Multihoming................................................ 16
5.7 Transition Considerations.................................. 16
5.8 Coexistence with firewall, NAT or RSIP..................... 16
5.9 Usage within Intranets..................................... 17
5.10 Summary of impact on routing.............................. 18
5.11. Routing loop prevention.................................. 18
6. Multicast and Anycast....................................... 19
7. ICMP messages............................................... 19
8. IANA Considerations......................................... 19
9. Security Considerations..................................... 19
Acknowledgements............................................... 20
References..................................................... 20
Authors' Addresses............................................. 22
Intellectual Property.......................................... 22
Full Copyright Statement....................................... 23
1.
This memo specifies an optional interim mechanism for IPv6 sites
communicate with each other over the IPv4 network without
tunnel setup, and for them to communicate with native IPv6
via relay routers. Effectively it treats the wide area IPv4
as a unicast point-to-point link layer. The mechanism is intended
a start-up transition tool used during the period of co-existence
IPv4 and IPv6. It is not intended as a permanent solution
Carpenter & Moore Standards Track [Page 2]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
The document defines a method for assigning an interim unique IPv
address prefix to any site that currently has at least one
unique IPv4 address, and specifies an encapsulation mechanism
transmitting IPv6 packets using such a prefix over the global IPv
network. It also describes scenarios for using such prefixes
the co-existence phase of IPv4 to IPv6 transition. Note that
scenarios are only part of the total picture of transition to IPv6.
Also note that this is considered to be an interim solution and
sites should migrate when possible to native IPv6 prefixes and
IPv6 connectivity. This will be possible as soon as the site's
offers native IPv6 connectivity
The basic mechanism described in the present document, which
to sites rather than individual hosts, will scale indefinitely
limiting the number of sites served by a given relay router (
Section 5.2). It will introduce no new entries in the IPv4
table, and exactly one new entry in the native IPv6 routing
(see Section 5.10).
Although the mechanism is specified for an IPv6 site, it can
be applied to an individual IPv6 host or very small site, as long
it has at least one globally unique IPv4 address. However,
latter case raises serious scaling issues which are the subject
further study [SCALE].
The motivation for this method is to allow isolated IPv6 sites
hosts, attached to a wide area network which has no native IPv
support, to communicate with other such IPv6 domains or hosts
minimal manual configuration
IPv6 sites or hosts connected using this method do not require IPv4-
compatible IPv6 addresses [MECH] or configured tunnels. In this
IPv6 gains considerable independence of the underlying wide
network and can step over many hops of IPv4 subnets. The
name of this mechanism is 6to4 (not to be confused with [6OVER4]).
The 6to4 mechanism is typically implemented almost entirely in
routers, without specific host modifications except a
address selection default. Only a modest amount of
configuration is required
Sections 2 to 4 of this document specify the 6to4 scheme technically
Section 5 discusses some, but not all, usage scenarios,
routing aspects, for 6to4 sites. Scenarios for isolated 6to4
are not discussed in this document. Sections 6 to 9 discuss
general considerations
Carpenter & Moore Standards Track [Page 3]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.1.
The terminology of [IPV6] applies to this document
6to4 pseudo-interface
6to4 encapsulation of IPv6 packets inside IPv4 packets
at a point that is logically equivalent to an IPv6 interface
with the link layer being the IPv4 unicast network. This
is referred to as a pseudo-interface. Some implementors
treat it exactly like any other interface and others may
it like a tunnel end-point
6to4 prefix
an IPv6 prefix constructed according to the rule in Section 2
below
6to4 address: an IPv6 address constructed using a 6to4 prefix
Native IPv6 address: an IPv6 address constructed using another
of prefix than 6to4.
6to4 router (or 6to4 border router):
an IPv6 router supporting a 6to4 pseudo-interface. It
normally the border router between an IPv6 site and a wide-
IPv4 network
6to4 host
an IPv6 host which happens to have at least one 6to4 address
In all other respects it is a standard IPv6 host
Note: an IPv6 node may in some cases use a 6to4 address for
configured tunnel. Such a node may function as an IPv6 host using
6to4 address on its configured tunnel interface, and it may
serve as a IPv6 router for other hosts via a 6to4 pseudo-interface
but these are distinct functions
6to4 site
a site running IPv6 internally using 6to4 addresses,
containing at least one 6to4 host and at least one 6to4 router
Carpenter & Moore Standards Track [Page 4]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Relay router
a 6to4 router configured to support transit routing
6to4 addresses and native IPv6 addresses
6to4 exterior routing domain
a routing domain interconnecting a set of 6to4 routers
relay routers. It is distinct from an IPv6 site's
routing domain, and distinct from all native IPv6
routing domains
2. IPv6 Prefix
Suppose that a subscriber site has at least one valid,
unique 32-bit IPv4 address, referred to in this document as V4ADDR
This address MUST be duly allocated to the site by an
registry (possibly via a service provider) and it MUST NOT be
private address [RFC 1918].
The IANA has permanently assigned one 13-bit IPv6 Top
Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH
AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it
2002::/16 when expressed as an IPv6 address prefix
The subscriber site is then deemed to have the following IPv6
prefix, without any further assignment procedures being necessary
Prefix length: 48
Format prefix: 001
TLA value: 0x0002
NLA value: V4
This is illustrated as follows
| 3 | 13 | 32 | 16 | 64 bits |
+---+------+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001|0x0002| | | |
+---+------+-----------+--------+--------------------------------+
Thus, this prefix has exactly the same format as normal /48
assigned according to [AGGR]. It can be abbreviated
2002:V4ADDR::/48. Within the subscriber site it can be used
like any other valid IPv6 prefix, e.g., for automated
assignment and discovery according to the normal mechanisms such
[CONF, DISC], for native IPv6 routing, or for the "6over4"
[6OVER4].
Carpenter & Moore Standards Track [Page 5]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Note that if the IPv4 address is assigned dynamically,
corresponding IPv6 prefix will also be dynamic in nature, with
same lifetime
2.1 Address
To ensure the correct operation of 6to4 in complex topologies,
and destination address selection must be appropriately implemented
If the source IPv6 host sending a packet has at least one 2002::
address assigned to it, and if the set of IPv6 addresses returned
the DNS for the destination host contains at least one 2002::
address, then the source host must make an appropriate choice of
source and destination addresses to be used. The mechanisms
address selection in general are under study at the time of
[SELECT]. Subject to those general mechanisms, the principle
will normally allow correct operation of 6to4 is this
If one host has only a 6to4 address, and the other one has both
6to4 and a native IPv6 address, then the 6to4 address should be
for both
If both hosts have a 6to4 address and a native IPv6 address,
either the 6to4 address should be used for both, or the native IPv
address should be used for both. The choice should be configurable
The default configuration should be native IPv6 for both
3. Encapsulation in IPv
IPv6 packets from a 6to4 site are encapsulated in IPv4 packets
they leave the site via its external IPv4 connection. Note that
IPv4 interface that is carrying the 6to4 traffic is
equivalent to an IPv6 interface, and is referred to below as
pseudo-interface, although this phrase is not intended to define
implementation technique. V4ADDR MUST be configured on the IPv
interface
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv
protocol type of 41, the same as has been assigned [MECH] for IPv
packets that are tunneled inside of IPv4 frames. The IPv4
contains the Destination and Source IPv4 addresses. One or both
these will be identical to the V4ADDR field of an IPv6 prefix
as specified above (see section 5 for more details). The IPv4
body contains the IPv6 header and payload
Carpenter & Moore Standards Track [Page 6]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
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 ... /
+-------+-------+-------+-------+-------+------+------+
The IPv4 Time to Live will be set as normal [RFC 791], as will
encapsulated IPv6 hop limit [IPv6]. Other considerations are
described in Section 4.1.2 of [MECH].
3.1. Link-Local Address and
The link-local address of a 6to4 pseudo-interface performing 6to
encapsulation would, if needed, be formed as described in Section 3.7
of [MECH]. However, no scenario is known in which such an
would be useful, since a peer 6to4 gateway cannot determine
appropriate link-layer (IPv4) address to send to
Neighbor Unreachability Detection (NUD) is handled as described
Section 3.8 of [MECH].
4. Maximum Transmission
MTU size considerations are as described for tunnels in [MECH].
If the IPv6 MTU size proves to be too large for some
IPv4 subnet, IPv4 fragmentation will ensue. While undesirable,
is not necessarily disastrous, unless the fragments are delivered
different IPv4 destinations due to some form of IPv4 anycast.
IPv4 "do not fragment" bit SHOULD NOT be set in the
IPv4 header
Carpenter & Moore Standards Track [Page 7]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
5. Unicast scenarios, scaling, and transition to normal
5.1 Simple scenario - all sites work the
The simplest deployment scenario for 6to4 is to use it between
number of sites, each of which has at least one connection to
shared IPv4 Internet. This could be the global Internet, or it
be a corporate IP network. In the case of the global Internet,
is no requirement that the sites all connect to the same
service provider. The only requirement is that any of the sites
able to send IPv4 packets with protocol type 41 to any of the others
By definition, each site has an IPv6 prefix in the format defined
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
records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48
(i.e., 2002:c001:0203::/48). Site B which owns address 9.254.253.252
will create DNS records with the IPv6
{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48).
When an IPv6 host on site B queries the DNS entry for a host on
A, or otherwise obtains its address, it obtains an address with
prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA
Interface ID applies. The converse applies when a host on site
queries the DNS for a host on site B. IPv6 packets are formed
transmitted in the normal way within both sites
_______________________________
| |
| Wide Area IPv4 Network |
|_______________________________|
/ \
192.1.2.3/ 9.254.253.252\
_______________________________/_ ____________________\____________
| / | | \ |
|IPv4 Site A ########## | |IPv4 Site B ########## |
| ____________________# 6to4 #_ | | ____________________# 6to4 #_ |
|| # router # || || # router # ||
||IPv6 Site A ########## || ||IPv6 Site B ########## ||
||2002:c001:0203::/48 || ||2002:09fe:fdfc::/48 ||
||_______________________________|| ||_______________________________||
| | | |
|_________________________________| |_________________________________|
Within a 6to4 site, addresses with the 2002::/16 prefix, apart
those with the local 2002:V4ADDR::/48 prefix, will be handled
any other non-local IPv6 address, i.e., by a default or
route towards the 6to4 border router
Carpenter & Moore Standards Track [Page 8]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
When an outgoing packet reaches the 6to4 router, it is
as defined in Section 3, according to the additional sending
defined in Section 5.3. Incoming packets are decapsulated
to the additional decapsulation rule defined in Section 5.3.
additional sending and decapsulation rules are the only changes
IPv6 forwarding, and they occur only at border routers. No IPv
routing information is imported into IPv6 routing (nor vice versa).
In this scenario, any number of 6to4 sites can interoperate with
tunnel configuration, and no special requirements from the IPv
service. All that is required is the appropriate DNS entries and
additional sending and decapsulation rules configured in the 6to
router. This router SHOULD also generate the appropriate IPv6
announcements [CONF, DISC].
Although site A and site B will each need to run IPv6
internally, they do not need to run an IPv6 exterior routing
in this simple scenario; IPv4 exterior routing does the job for them
It is RECOMMENDED that in any case each site should use only one IPv
address per 6to4 router, and that should be the address assigned
the external interface of the 6to4 router. Single-homed
therefore SHOULD use only one IPv4 address for 6to4 routing. Multi
homed sites are discussed briefly in section 5.6.
Because of the lack of configuration, and the distributed
model, there are believed to be no particular scaling issues with
basic 6to4 mechanism apart from encapsulation overhead
Specifically, it introduces no new entries in IPv4 routing tables
5.2 Mixed scenario with relay to native IPv
During the transition to IPv6 we can expect some sites to fit
model just described (isolated sites whose only connectivity is
IPv4 Internet), whereas others will be part of larger islands
native or tunneled IPv6 using normal IPv6 TLA address space.
6to4 sites will need connectivity to these native IPv6 islands
vice versa. In the 6to4 model, this connectivity is accomplished
IPv6 routers which possess both 6to4 and native IPv6 addresses
Although they behave essentially as standard IPv6 routers, for
purposes of this document they are referred to as relay routers
distinguish them from routers supporting only 6to4, or only
IPv6.
There must be at least one router acting as a relay between the 6to
domain and a given native IPv6 domain. There is nothing
about it; it is simply a normal router which happens to have at
Carpenter & Moore Standards Track [Page 9]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
one logical 6to4 pseudo-interface and at least one other IPv
interface. Since it is a 6to4 router, it implements the
sending and decapsulation rules defined in Section 5.3.
We now have three distinct classes of routing domain to consider
1. the internal IPv6 routing domain of each 6to4 site
2. an exterior IPv6 routing domain
a given set of 6to4 border routers, including relay routers
among themselves, i.e., a 6to4 exterior routing domain
3. the exterior IPv6 routing domain of each native IPv6 island
1. The internal routing domain of a 6to4 site behaves as described
section 5.1.
2. There are two deployment options for a 6to4 exterior
domain
2.1 No IPv6 exterior routing protocol is used. The 6to4
using a given relay router each have a default IPv6 route pointing
the relay router. The relay router MAY apply source address
filters to accept traffic only from specific 6to4 routers
2.2 An IPv6 exterior routing protocol is used. The set of 6to
routers using a given relay router obtain native IPv6 routes from
relay router using a routing protocol such as BGP4+ [RFC 2283,
BGP4+]. The relay router will advertise whatever native IPv6
prefixes are appropriate on its 6to4 pseudo-interface.
prefixes will indicate the regions of native IPv6 topology that
relay router is willing to relay to. Their choice is a matter
routing policy. It is necessary for network operators to
consider desirable traffic patterns and topology when choosing
scope of such routing advertisements. The relay router
establish BGP peering only with specific 6to4 routers whose
it is willing to accept
Although this solution is more complex, it provides effective
control, i.e., BGP4+ policy determines which 6to4 routers are able
use which relay router
3. A relay router MUST advertise a route to 2002::/16 into the
IPv6 exterior routing domain. It is a matter of routing policy
far this routing advertisement of 2002::/16 is propagated in
native IPv6 routing system. Since there will in general be
relay routers advertising it, network operators will require
filter it in a managed way. Incorrect policy in this area will
to potential unreachability or to perverse traffic patterns
Carpenter & Moore Standards Track [Page 10]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
6to4 prefixes more specific than 2002::/16 must not be propagated
native IPv6 routing, to prevent pollution of the IPv6 routing
by elements of the IPv4 routing table. Therefore, a 6to4 site
also has a native IPv6 connection MUST NOT advertise its 2002::/48
routing prefix on that connection, and all native IPv6
operators MUST filter out and discard any 2002:: routing
advertisements longer than /16.
Sites which have at least one native IPv6 connection, in addition
a 6to4 connection, will therefore have at least one IPv6 prefix
is not a 2002:: prefix. Such sites' DNS entries will reflect
and DNS lookups will return multiple addresses. If two such
need to interoperate, whether the 6to4 route or the native route
be used depends on IPv6 address selection by the individual hosts (
even applications).
Now consider again the example of the previous section. Suppose
IPv6 host on site B queries the DNS entry for a host on site A,
the DNS returns multiple IPv6 addresses with different prefixes
____________________________ ______________________
| | | |
| Wide Area IPv4 Network | | Native IPv6 |
| | | Wide Area Network |
|____________________________| |______________________|
/ \ //
192.1.2.3/ 9.254.253.252\ // 2001:0600::/48
____________/_ ____________________\_________//_
/ | | \ // |
########## | |IPv4 Site B ########## |
__# 6to4 #_ | | ____________________# 6to4 #_ |
# router # || || # router # ||
########## || ||IPv6 Site B ########## ||
|| ||2002:09fe:fdfc::/48 ||
__Site A_____|| ||2001:0600::/48_________________||
as before | | |
______________| |_________________________________|
If the host picks the 6to4 prefix according to some rule for
prefixes, it will simply send packets to an IPv6 address formed
the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is
that they are sourced from the
{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity
be possible. The address selection mechanism of Section 2.1
ensure this
Carpenter & Moore Standards Track [Page 11]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
5.2.1 Variant scenario with ISP
The previous scenario assumes that the relay router is provided by
cooperative 6to4 user site. A variant of this is for an
Service Provider, that already offers native IPv6 connectivity,
operate a relay router. Technically this is no different from
previous scenario; site B is simply an internal 6to4 site of the ISP
possibly containing only one system, i.e., the relay router itself
5.2.2 Summary of relay router
A relay router participates in IPv6 unicast routing protocols on
native IPv6 interface and may do so on its 6to4 pseudo-interface,
these are independent routing domains with separate policies, even
the same protocol, probably BGP4+, is used in both cases
A relay router also participates in IPv4 unicast routing protocols
its IPv4 interface used to support 6to4, but this is not
discussed here
On its native IPv6 interface, the relay router MUST advertise a
to 2002::/16. It MUST NOT advertise a longer 2002:: routing
on that interface. Routing policy within the native IPv6
domain determines the scope of that advertisement, thereby
the visibility of the relay router in that domain
IPv6 packets received by the relay router whose next hop IPv6
matches 2002::/16 will be routed to its 6to4 pseudo-interface
treated according to the sending rule of Section 5.1.
5.2.2.1. BGP4+ not
If BGP4+ is not deployed in the 6to4 exterior routing domain (
2.1 of Section 5.2), the relay router will be configured to
and relay all IPv6 traffic only from its client 6to4 sites.
6to4 router served by the relay router will be configured with
default IPv6 route to the relay router (for example, Site A's
IPv6 route ::/0 would point to the relay router's address
prefix 2002:09fe:fdfc::/48).
5.2.2.2. BGP4+
If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2
of Section 5.2), the relay router advertises IPv6 native
prefixes on its 6to4 pseudo-interface, peering only with the 6to
routers that it serves. (An alternative is that these routes
be advertised along with IPv4 routes using BGP4 over IPv4,
than by running a separate BGP4+ session.) The specific
Carpenter & Moore Standards Track [Page 12]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
advertised depend on applicable routing policy, but they must
chosen from among those reachable through the relay router's
IPv6 interface. In the simplest case, a default route to the
IPv6 address space could be advertised. When multiple relay
are in use, more specific routing prefixes would be
according to the desired routing policy. The usage of BGP4+
completely standard so is not discussed further in this document
5.2.2.3. Relay router
Relay routers introduce the potential for scaling issues. In
a relay router should not attempt to serve more sites than any
transit router, allowing for the encapsulation overhead
5.2.3 Unwilling to
It may arise that a site has a router with both 6to4 pseudo
interfaces and native IPv6 interfaces, but is unwilling to act as
relay router. Such a site MUST NOT advertise any 2002::
prefix into the native IPv6 domain and MUST NOT advertise any
IPv6 routing prefixes or a default IPv6 route into the 6to4 domain
Within the 6to4 domain it will behave exactly as in the basic 6to
scenario of Section 5.1.
5.3 Sending and decapsulation
The only change to standard IPv6 forwarding is that every 6to4
(and only 6to4 routers) MUST implement the following
sending and decapsulation rules
In the sending rule, "next hop" refers to the next IPv6 node that
packet will be sent to, which is not necessarily the
destination, but rather the next IPv6 neighbor indicated by
IPv6 routing mechanisms. If the final destination is a 6to4 address
it will be considered as the next hop for the purpose of this rule
If the final destination is not a 6to4 address, and is not local,
next hop indicated by routing will be the 6to4 address of a
router
ADDITIONAL SENDING RULE for 6to4
if the next hop IPv6 address for an IPv6
does match the prefix 2002::/16,
does not match any prefix of the local
apply any security checks (see Section 8);
encapsulate the packet in IPv4 as in Section 3,
Carpenter & Moore Standards Track [Page 13]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
with IPv4 destination address = the NLA value V4
extracted from the next hop IPv6 address
queue the packet for IPv4 forwarding
A simple decapsulation rule for incoming IPv4 packets with
type 41 MUST be implemented
ADDITIONAL DECAPSULATION RULE for 6to4
apply any security checks (see Section 8);
remove the IPv4 header
submit the packet to local IPv6 routing
5.4 Variant scenario with tunnel to IPv6
A 6to4 site which has no IPv6 connections to the "native" IPv
Internet can acquire effective connectivity to the v6 Internet via
"configured tunnel" (using the terminology in [MECH]) to
cooperating router which does have IPv6 access, but which does
need to be a 6to4 router. Such tunnels could be autoconfigured
an IPv4 anycast address, but this is outside of the scope of
document. Alternatively a tunnel broker can be used. This
would be suitable for a small user-managed site
These mechanisms are not described in detail in this document
5.5 Fragmented
If there are multiple relay routers between native IPv6 and the 6to
world, different parts of the 6to4 world will be served by
relays. The only complexity that this introduces is in the
of 2002::/16 routing advertisements within the native IPv6 world
Like any BGP4+ advertisements, their scope must be correctly
by routing policy to ensure that traffic to 2002::/16 follows
intended paths
If there are multiple IPv6 stubs all interconnected by 6to4
the global IPv4 Internet, this is a simple generalization of
basic scenarios of sections 5.1. and 5.2 and no new issues arise
This is shown in the following figure. Subject to
configuration of routing advertisements, there are no known
with this scenario
Carpenter & Moore Standards Track [Page 14]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2
| AS1 | AS2 | 2002::/16, but only one
|______|_______| them reaches AS3.
// \\
__________//_ _\\__________ ______________
| 6to4 Relay1 | | 6to4 Relay2 | | IPv6 Network |
|_____________| |_____________| | AS4 |
| | |______________|
________|______________________|________ |
| | ______|______
| Global IPv4 Network |-----| 6to4 Relay3 |
|________________________________________| |_____________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|
If multiple IPv6 stubs are interconnected through multiple,
IPv4 networks (i.e., a fragmented IPv4 world) then the 6to4 world
also fragmented; this is the one scenario that must be avoided.
is illustrated below to show why it does not work, since
2002::/16 advertisement from Relay1 will be invisible to Relay2,
vice versa. Sites A and B therefore have no connectivity to sites
and D
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2
| AS1 | AS2 | 2002::/16, but sites A and
|______|_______| cannot reach C and D
// \\
__________//_ _\\__________
| 6to4 Relay1 | | 6to4 Relay2 |
|_____________| |_____________|
| |
________|_______ _______|________
| IPv4 Network | | IPv4 Network |
| Segment 1 | | Segment 2 |
|________________| |________________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|
Carpenter & Moore Standards Track [Page 15]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
5.6
Sites which are multihomed on IPv4 MAY extend the 6to4 scenario
using a 2002:: prefix for each IPv4 border router, thereby
a simple form of IPv6 multihoming by using multiple simultaneous IPv
prefixes and multiple simultaneous relay routers
5.7 Transition
If the above rules for routing advertisements and address
are followed, then a site can migrate from using 6to4 to using
IPv6 connections over a long period of co-existence, with no need
stop 6to4 until it has ceased to be used. The stages involved
1. Run IPv6 on site using any suitable implementation. True
IPv6, [6OVER4], or tunnels are all acceptable
2. Configure a border router (or router plus IPv4 NAT) connected
the external IPv4 network to support 6to4, including advertising
appropriate 2002:: routing prefix locally. Configure IPv6
entries using this prefix. At this point the 6to4 mechanism
automatically available, and the site has obtained a "free" IPv
prefix
3. Identify a 6to4 relay router willing to relay the site's
to the native IPv6 world. This could either be at
cooperative 6to4 site, or an ISP service. If no exterior
protocol is in use in the 6to4 exterior routing domain, the site'
6to4 router will be configured with a default IPv6 route pointing
that relay router's 6to4 address. If an exterior routing
such as BGP4+ is in use, the site's 6to4 router will be configured
establish appropriate BGP peerings
4. When native external IPv6 connectivity becomes available, add
second (native) IPv6 prefix to both the border router
and the DNS configuration. At this point, an address selection
will determine when 6to4 and when native IPv6 will be used
5. When 6to4 usage is determined to have ceased (which may be
years later), remove the 6to4 configuration
5.8 Coexistence with firewall, NAT or
The 6to4 mechanisms appear to be unaffected by the presence of
firewall at the border router
Carpenter & Moore Standards Track [Page 16]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
If the site concerned has very limited global IPv4 address space,
is running an IPv4 network address translator (NAT), all of the
mechanisms remain valid. The NAT box must also contain a
functional IPv6 router including the 6to4 mechanism. The
used for V4ADDR will simply be a globally unique IPv4
allocated to the NAT. In the example of Section 5.1 above, the 6to
routers would also be the sites' IPv4 NATs, which would own
globally unique IPv4 addresses 192.1.2.3 and 9.254.253.252.
Combining a 6to4 router with an IPv4 NAT in this way offers the
concerned a globally unique IPv6 /48 prefix, automatically,
the IPv4 address of the NAT. Thus every host behind the NAT
become an IPv6 host with no need for additional address
allocation, and no intervention by the Internet service provider.
address translation is needed by these IPv6 hosts
A more complex situation arises if a host is more than one NAT
away from the globally unique IPv4 address space, since only
outermost NAT has a unique IPv4 address. All IPv6 hosts in
situation must use addresses derived from the 2002:
constructed from the global IPv4 address of the outermost NAT.
IPv4 addresses of the inner NATs are not globally unique and play
part in the 6to4 mechanism, and 6to4 encapsulation and
can only take place at the outermost NAT
The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist
6to4. If a 6to4 border router is combined with an RSIP
router, it can support IPv6 hosts using 6to4 addresses, IPv4
using RSIP, or dual stack hosts using both. The RSIP
provides fine-grained management of dynamic global IPv4
allocation and the 6to4 function provides a stable IPv6
address to each host. As with NAT, the IPv4 address used
construct the site's 2002: prefix will be one of the
addresses of the RSIP border router
5.9 Usage within
There is nothing to stop the above scenario being deployed within
private corporate network as part of its internal transition to IPv6;
the corporate IPv4 backbone would serve as the virtual link layer
individual corporate sites using 2002:: prefixes. The V4ADDR MUST
a duly allocated global IPv4 address, which MUST be unique within
private network. The Intranet thereby obtains globally unique IPv
addresses even if it is internally using private IPv4 addresses [
1918].
Carpenter & Moore Standards Track [Page 17]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
5.10 Summary of impact on
IGP (site) routing will treat the local site's 2002::/48
exactly like a native IPv6 site prefix assigned to the local site
There will also be an IGP route to the generic 2002::/16 prefix
which will be a route to the site's 6to4 router, unless this
handled as a default route
EGP (i.e., BGP) routing will include advertisements for the 2002::/16
prefix from relay routers into the native IPv6 domain, whose scope
limited by routing policy. This is the only non-native IPv6
advertised by BGP
It will be necessary for 6to4 routers to obtain routes to
routers in order to access the native IPv6 domain. In the
case there will be a manually configured default IPv6 route to
relay router's address under the
{FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4
of the relay router. Such a route could be used to establish a
session for the exchange of additional IPv6 routes
By construction, unicast IPv6 traffic within a 6to4 domain
follow exactly the same path as unicast IPv4 traffic
5.11. Routing loop
Since 6to4 has no impact on IPv4 routing, it cannot induce
loops in IPv4. Since 2002: prefixes behave exactly like
IPv6 prefixes, they will not create any new mechanisms for
loops in IPv6 unless misconfigured. One very
misconfiguration would be an announcement of the 2002::/16
into a 6to4 exterior routing domain, since this would attract
6to4 traffic into the site making the announcement. Its 6to4
would then resend non-local 6to4 traffic back out, forming a loop
The 2002::/16 routing prefix may be legitimately advertised into
native IPv6 routing domain by a relay router, and into an IPv6 site'
local IPv6 routing domain; hence there is a risk of
causing it to be advertised into a 6to4 exterior routing domain
To summarize, the 2002::/16 prefix MUST NOT be advertised to a 6to
exterior routing domain
Carpenter & Moore Standards Track [Page 18]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
6. Multicast and
It is not possible to assume the general availability of wide-
IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must
only unicast capability in its underlying IPv4 carrier network.
IPv6 multicast routing protocol is needed [MULTI].
The allocated anycast address space [ANYCAST] is compatible
2002:: prefixes, i.e., anycast addresses formed with such
may be used inside a 6to4 site
7. ICMP
ICMP "unreachable" and other messages returned by the IPv4
system will be returned to the 6to4 router that generated
encapsulated 2002:: packet. However, this router will often
unable to return an ICMPv6 message to the originating IPv6 node,
to the lack of sufficient information in the "unreachable" message
This means that the IPv4 network will appear as an undiagnosable
layer for IPv6 operational purposes. Other considerations are
described in Section 4.1.3 of [MECH].
8. IANA
No assignments by the IANA are required beyond the special TLA
0x0002 already assigned
9. Security
Implementors should be aware that, in addition to possible
against IPv6, security attacks against IPv4 must also be considered
Use of IP security at both IPv4 and IPv6 levels should
be avoided, for efficiency reasons. For example, if IPv6 is
encrypted, encryption of IPv4 would be redundant except if
analysis is felt to be a threat. If IPv6 is running authenticated
then authentication of IPv4 will add little. Conversely, IPv
security will not protect IPv6 traffic once it leaves the 6to
domain. Therefore, implementing IPv6 security is required even
IPv4 security is available
By default, 6to4 traffic will be accepted and decapsulated from
source from which regular IPv4 traffic is accepted. If this is
any reason felt to be a security risk (for example, if IPv6
is felt to be more likely than IPv4 spoofing), then additional
address based packet filtering could be applied. A
plausibility check is whether the encapsulating IPv4 address
consistent with the encapsulated 2002:: address. If this check
Carpenter & Moore Standards Track [Page 19]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
applied, exceptions to it must be configured to admit traffic
relay routers (Section 5). 2002:: traffic must also be excepted
checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].
In any case, any 6to4 traffic whose source or destination
embeds a V4ADDR which is not in the format of a global
address MUST be silently discarded by both encapsulators
decapsulators. Specifically, this means that IPv4 addresses
in [RFC 1918], broadcast, subnet broadcast, multicast and
addresses are unacceptable
The basic idea presented above is probably not original, and we
had invaluable comments from Magnus Ahltorp, Harald Alvestrand,
Bound, Scott Bradner, Randy Bush, Matt Crawford, Richard Draves
Jun-ichiro itojun Hagino, Joel Halpern, Tony Hain, Andy Hazeltine
Bob Hinden, Geoff Huston, Perry Metzger, Thomas Narten,
Nordmark, Markku Savela, Ole Troan, Sowmini Varadhan, members of
Compaq IPv6 engineering team, and other members of the
working group. Some text has been copied from [6OVER4].
Tsirtsis kindly drafted two of the diagrams
[AARCH] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[AGGR] Hinden., R, O'Dell, M. and S. Deering, "An IPv
Aggregatable Global Unicast Address Format", RFC 2374,
July 1998.
[API] Gilligan, R., Thomson, S., Bound, J. and W. Stevens
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[BGP4+] Marques, P. and F. Dupont, "Use of BGP-4
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
1999.
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998.
[DISC] Narten, T., Nordmark, E. and W. Simpson, "
Discovery for IP Version 6 (IPv6)", RFC 2461,
1998.
Carpenter & Moore Standards Track [Page 20]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv
Domains without Explicit Tunnels", RFC 2529, March 1999.
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet
Addresses", Work in Progress
[MULTI] Thaler, D., "Support for Multicast over 6to4 Networks",
Work in Progress
[SCALE] Hain, T., "6to4-relay discovery and scaling", Work
Progress
[SELECT] Draves, R., "Default Address Selection for IPv6", Work
Progress
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981.
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Tuniguchi
"Realm Specific IP: Protocol Specification", Work
Progress
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter
"Multiprotocol Extensions for BGP-4", RFC 2283,
1998.
Carpenter & Moore Standards Track [Page 21]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Authors'
Brian E.
iCAIR, Suite 150
1890 Maple
Evanston IL 60201,
EMail: brian@icair.
Keith
UT Computer Science
1122 Volunteer Blvd, Ste 203
Knoxville, TN 37996-3450
EMail: moore@cs.utk.
Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
Carpenter & Moore Standards Track [Page 22]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Carpenter & Moore Standards Track [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
