WDIFF

draft-ietf-ngtrans-6to4-02.txt --> draft-ietf-ngtrans-6to4-03.txt

Internet Draft K. Moore
June
Oct 1999

Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels

Placeholder for ISOC copyright.

Abstract

draft-ietf-ngtrans-6to4-02.txt

draft-ietf-ngtrans-6to4-03.txt

The motivation for this method is to allow isolated IPv6 domains, domains or
hosts, attached to an IPv4 network which has no native IPv6 support,
to communicate with other such IPv6 domains or hosts with minimal
manual configuration. Effectively it treats the IPv4 network as a
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 December 1999 April 2000 [Page 1]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

Table of Contents:

Status of this Memo.............................................1
0. Changes and Issues...........................................3 Issues (remove prior to RFC publication..........3
1. Introduction.................................................3
2. IPv6 Prefix Allocation.......................................4
2.1 Address Selection Algorithm.................................5
3. Encapsulation in IPv4........................................5
4. Maximum Transmission Unit....................................5
4. Frame Format.................................................5 Unit....................................6
5. Unicast scenarios, scaling, and transition to normal prefixes6
5.1 Simple scenario - all sites work the same...................6
5.2 Mixed scenario with relay to native IPv6....................8
5.2.1 Variant scenario with ISP relay..........................10
5.2.2 Summary of relay router configuration....................10
5.2.3 Unwilling to relay.......................................11
5.3 Variant scenario with tunnel to IPv6 space.................11
5.4 Multihoming................................................11 Fragmented Scenarios.......................................11
5.5 Transition considerations..................................11 Multihoming................................................12
5.6 Transition considerations..................................13
5.7 Usage with firewall or NAT.................................12
5.7 NAT.................................13
5.8 Usage within Intranets.....................................12
5.8 Intranets.....................................14
5.9 Summary of impact on routing...............................13 routing...............................14
6. Multicast and Anycast.......................................13 Anycast.......................................15
7. ICMP messages...............................................14 messages...............................................15
8. IANA considerations.........................................14 considerations.........................................15
9. Security considerations.....................................14
Acknowledgements...............................................15
References.....................................................16 considerations.....................................15
Acknowledgements...............................................16
References.....................................................17
Authors' Addresses.............................................16 Addresses.............................................17
Intellectual Property..........................................17 Property..........................................18
Full Copyright Statement.......................................17 Statement.......................................18

Carpenter + Moore Expires December 1999 April 2000 [Page 2]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

0. Changes and Issues (remove prior to RFC publication
Changes from 02 to 03 version:

- changed to officially assigned TLA value
- sections of text re-ordered for clarity
- "do not fragment" is now SHOULD NOT (adopting the decision
reached for 6over4)
- new version of address selection text
- bogus MTU text deleted
- a few additional scenarios and pictures added
- general text clarifications and response to detail comments

Changes from 01 to 02 version:

- added some pictures
- added sub-section on relay via ISP
- added scenario on usage with configured tunnels
- improved discussion of routing
- improved and moved discussion of multicast
- added section on relay router config
- added note on incongruent routing
- minor fixes

Issues, and points not added:

- there is debate about how 6to4 sites locate relay routers;
do they have to make EGP routing announcements?
- draft recommends generic address selection algorithm;
not everybody wants this.
- soemone observed that configured tunnels can co-exist
with IPv4 NAT; true, but doesn't belong here.
- discarded suggestion of scrambling (inverting)
bit order in 6to4 prefix; doesn't buy anything
except confusion.

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 specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network. It also describes scenarios for using such prefixes 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 IPv6.

Although the mechanisms in [RFC 1933]. mechanism is specified for an IPv6 site, it can equally
be applied to an individual IPv6 host, as long as it has at least one
globally unique IPv4 address.

The motivation for this method is to allow isolated IPv6 domains, sites or
hosts, attached to a wide area network which has no native IPv6
support, to communicate with other such IPv6 domains or hosts with
minimal manual configuration. Effectively it treats the wide area
IPv4 network as a point-to-point link layer.

IPv6 domains sites or hosts 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 typically implemented almost entirely in border
routers, without specfic specific host modifications except a recommended

Carpenter + Moore Expires April 2000 [Page 3]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

address selection algorithm. Only a modest amount of router
configuration is required.

Sections 2 to 4 of this document specify the 6to4 scheme technically.
Section 5 discusses some, but not all, usage scenarios, including
routing aspects, for 6to4 sites. Scenarios for isolated 6to4 hosts
will be discussed in another document. Sections 6 to 9 discuss other
general considerations.

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].

Carpenter + Moore Expires December 1999 [Page 3]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

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
AGGR] for the 6to4 scheme.Its numeric value is
0x0010.

[*** temporary note - this assignment remains to be made and may
change ***]

The subscriber site 0x0002, i.e., it is
2002::/16 when expressed as an IPv6 address prefix.

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 0x0002
NLA value: V4ADDR

Carpenter + Moore Expires December 1999 April 2000 [Page 4]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

This is illustrated as follows:

| 3 | 13 | 32 | 16 | 64 bits |
+---+-----+-----------+--------+--------------------------------+
+---+------+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001| 624 |
|001|0x0002| | | |
+---+-----+-----------+--------+--------------------------------+
+---+------+-----------+--------+--------------------------------+

Thus, this prefix has exactly the same format as normal prefixes
assigned according to [AGGR]. Within the subscriber site it can be
used exactly like any other valid IPv6 prefix, e.g., for automated
address assignment and discovery anddiscovery according to the normal mechanisms
such as [CONF, DISC].

If the subscriber site is not yet running DISC], for native IPv6, but is running
IPv4 multicast, this "6 to 4" address prefix can be used in
conjunction with IPv6 routing, or for the "6 over 4" "6over4"
mechanism [6OVER4]. Thus isolated

2.1 Address Selection Algorithm

To ensure the correct operation of 6to4 in complex topologies, all
IPv6 hosts within isolated MUST provide the following algorithm, or its equivalent,
for address selection when sending IPv6 domains can communicate by using "6
over 4" to packets. This algorithm
SHOULD be enabled whenever a border router and "6 source host has at least one 2002::
prefix assigned to 4" over the wide area.

3. Maximum Transmission Unit it.

If the set of IPv6 MTU size proves to be too large addresses returned by the DNS 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 destination
host contains at least one 2002:: address, then the source host MUST NOT be set in
choose a 2002:: address for both the encapsulating source and destination of the
IPv6 packet.

3. Encapsulation in IPv4
header.

The default MTU size for

IPv6 packets is 1280 octets [IPV6], which is
greater than the specified minimum from a 6to4 site are encapsulated in IPv4 MTU size of 576 octets [RFC
791]. In packets when
they leave the event site via its external IPv4 connection. Note that the IPv6 Path MTU
IPv4 interface that is discovered to be less
than 1280 octets, carrying the 6to4 router MUST return traffic is notionally
equivalent to an ICMP Packet Too Big
message reporting IPv6 interface, and is referred to below as 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
pseudo-interface, although this does phrase is not require any modification intended to define an IPv6 host conforming to [IPv6]. Other considerations are as
described in Section 4.1.1 of [RFC 1933].

4. Frame Format
implementation technique.

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 December 1999 April 2000 [Page 5]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

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].

4. 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 SHOULD NOT be set in the encapsulating
IPv4 header.

5. Unicast scenarios, scaling, and transition to normal prefixes

5.1 Simple scenario - all sites work the same

The simplest deployment scenario for 6to4 is to use it between a
number of sites, each of which has at least one connection to a
shared IPv4 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 with protocol type 41 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

Carpenter + Moore Expires April 2000 [Page 6]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

records with the IPv6 prefix {FP=001,TLA=TLA624,NLA=192.1.2.3}/48. {FP=001,TLA=0x0002,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. {FP=001,TLA=0x0002,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 or otherwise obtains its address, it obtains an address with the
prefix
{FP=001,TLA=TLA624,NLA=192.1.2.3}/48 {FP=001,TLA=0x0002,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.

Carpenter + Moore Expires December 1999 [Page 6]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999
_______________________________
| |
| 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 ########## ||
||2010:c001:0203::/48
||2002:c001:0203::/48 || ||2010:09fe:fdfc::/48 ||2002:09fe:fdfc::/48 ||
||_______________________________|| ||_______________________________||
| | | |
|_________________________________| |_________________________________|

Within a 6to4 site, the 2002::/16 prefix will normally be handled as
a default route towards the 6to4 border router. The only change to
standard IPv6 routing is that the border 6to4 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 non-local
and the NLA field destination prefix is an IPv4 address assigned to this site 2002::/16
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 MUST be implemented:
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 border
routers.

In this scenario, any number of 6to4 sites can interoperate with no
tunnel configuration, and no special requirements from the IPv4
service. All that is required is the appropriate DNS entries and the

Carpenter + Moore Expires April 2000 [Page 7]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

special sending rule configured in the 6to4 router. This router
SHOULD also generate the appropriate IPv6 prefix announcements [CONF,
DISC].

The sites are

Although site A and site B will each need to run IPv6 routing
internally, they do not required need to run an IPv6 unicast exterior routing protocol among
themselves
in a pure 6to4 scenario. this simple scenario; IPv4 exterior routing does the job for them.

It is RECOMMENDED that in any case each site should use only one IPv4
address per 6to4 router, and that should be the address assigned to
the external interface of the 6to4 router. Single-homed sites
therefore SHOULD use only one IPv4 address for 6to4 routing. Multi-

Carpenter + Moore Expires December 1999 [Page 7]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999
homed sites are discused in section 5.3. Note that the IPv4 interface
that is carrying the 6to4 traffic is logically equivalent to an IPv6
interface, and is referred to below as a pseudo-interface.

Because of the lack of configuration, and the distributed deployment
model, there are believed to be no particular scaling issues with the
pure
basic 6to4 mechanism. mechanism apart from encapsulation overhead.
Specifically, it introduces no new entries in IPv4 routing tables.

5.2 Mixed scenario with relay to native IPv6

Suppose one or more of

During the transition to IPv6 we can expect some sites to fit the
model just described above acquire (isolated sites whose only connectivity is the
IPv4 Internet), whereas others will be part of larger islands of
native or tunnelled IPv6 using normal IPv6 TLA address space. The
6to4 sites will need connectivity in addition to 6to4 connectivity. these native IPv6 islands and
vice versa. In the 6to4 model, this case it connectivity is
necessary to relay packets between the accomplished by
IPv6 routers which support both 6to4 realm and the native IPv6
realm. addresses.
Although they behave essentially as standard IPv6 routers, for the
purposes of this document they are referred to as relay routers to
distinguish them from routers supporting only 6to4, or only native
IPv6.

There must be at least one router acting as a relay. relay between the 6to4
realm and a given native IPv6 realm. There is nothing special about this;
it; it is simply a normal router which happens to have at least one
logical 6to4 pseudo-interface and at
least one other IPv6 interface.

An IPv6 router willing to act as a relay from native 6to4 pseudo-interface and at least one other IPv6 interface.

We now have three distinct classes of routing domain to consider:

1. the internal IPv6 routing domain of each 6to4 site
2. the exterior IPv6 routing domain interconnecting
multiple 6to4
address space is known as a border routers, including relay router. It MUST advertise a route
to {FP=001,TLA=TLA624}/16 into routers,
among themselves
3. the native exterior IPv6 routing system.
Additionally, an domain of each native IPv6 unicast island

1. The internal routing protocol such domain of a 6to4 site behaves as BGP4+ MUST be
used among described in
section 5.1.

2. In the 6to4 exterior routing domain, the set of communicating 6to4 routers including using
the relay
router. router MUST obtain native IPv6 routes from the relay router

Carpenter + Moore Expires April 2000 [Page 8]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

using a routing protocol such as BGP4+. The relay router MUST
advertise whatever native IPv6 prefixes are appropriate on its 6to4
pseudo-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

3. A relay router MUST advertise a 6to4 site, route to 2002::/16 into the {FP=001,TLA=TLA624}/16 prefix will normally
be handled as a default route. native
IPv6 exterior routing domain. It is a matter of routing policy how
far the this advertisement of
{FP=001,TLA=TLA624}/16 2002::/16 is propagated. propagated in the native IPv6
routing system. Since there will presumably in general 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 2002::/48 prefix on that connection, and IPv6 network
operators MUST filter out and discard any TLA624 2002:: prefix
advertisements longer than /16.

Sites which have at least one native IPv6 connection, in addition to
a 6to4 connection, will therefore have at least one IPv6 prefix which
is not a TLA624 2002:: 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).

Carpenter + Moore Expires December 1999 [Page 8]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

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
{FP=001,TLA=TLA624,NLA=9.254.253.252}/48 for two-way connectivity to
be possible.

____________________________ ______________________
| | | |
| 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 ########## ||
|| ||2010:09fe:fdfc::/48 ||2002:09fe:fdfc::/48 ||
__Site A_____|| ||2001:0600::/48_________________||
as before | | |
______________| |_________________________________|

The following algorithm would result in correct 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 before | | |
______________| |_________________________________|

If the case of a
tie host picks the choice is arbitrary.

In practice address selection will proceed in two stages. First, a
call 6to4 prefix according to gethostbyname2 [API] some rule for multiple
prefixes, it will return a set of valid destination
addresses. It is RECOMMENDED that these should be sorted in order of
longest match simply send packets to an IPv6 address formed with
the host's set of valid source addresses. prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is then
the RECOMMENDED default that the host selects the first destination
address from essential that list and selects the source address with the
longest match.

Carpenter + Moore Expires December 1999 April 2000 [Page 9]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

they are sourced from the prefix
{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to
be possible. The address selection algorithm of Section 2.1 will
ensure this.

5.2.1 Variant scenario with ISP relay

The previous scenario assumes that the relay router is provided by a
cooperative 6to4 user site. An elementary variant of this is for an
Internet Service Provider, that already offers native offersnative IPv6
connectivity, to operate a relay router. Technically this is no
different from the 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 configuration

A relay router participates in IPv6 unicast routing protocols on its
native IPv6 interface and on its 6to4 pseudo-interface, but these are
independent routing realms with separate policies (even if the same
protocol, such as BGP4+, is used in both cases).

A relay router also participates in IPv4 unicast routing protocols on
its IPv4 interface used to support 6to4, but this is not further
discussed here.

On its native IPv6 interface, the relay router MUST advertise a route
to {FP=001,TLA=TLA624}/16. 2002::/16. It MUST NOT advertise a longer
{FP=001,TLA=TLA624} 2002:: prefix on that
interface. Routing policy within the native IPv6 routing realm
determines the scope of that advertisement, thereby limiting the
visibility of the relay router in that realm.

On its 6to4 IPv6 pseudo-interface, the relay router advertises
whatever IPv6 native prefixes its local policy permits, from among
those reachable through its native IPv6 interface. In the simplest
case, a default route to the whole IPv6 address space MAY could be
advertised. It has been suggested that these routes could actually by
advertised along with IPv4 routes using BGP4 over IPv4, rather than
by running a separate BGP4+ session.

In the event that BGP4 or BGP4+ is not available to it, a 6to4
routerserved by the relay router will be configured with a default
IPv6 route to the relay router (for example, Site A's default IPv6
route would be 2002:09fe:fdfc::/48).

Finally, given that there is no 6to4 router discovery protocol, a
route MUST will be configured in the relay router to each 6to4 router it is willing to serve
serves (for example, the relay router shown above must will be configured
with a route to Site A, i.e.
2010:c001:0203::/48). 2002:c001:0203::/48). Note that
configuring this route is the logical equivalent of configuring one
end of a configured tunnel [RFC 1933], but it will be managed as part

Carpenter + Moore Expires April 2000 [Page 10]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

of a routing configuration.

[**The following sentence is contested by some parties.**]
Conversely, each 6to4 router served by the relay router MUST be
configured with a default IPv6 route to the relay router (for
example, Site A's default IPv6 route will be 2010:09fe:fdfc::/48). configuration.

Clearly this requirement for explicit route configuration is an
operational scaling issue, but one configuration action per user site
is as little as can be reasonably expected. Additional mechanisms to
automate such configuration are for further study.

Relay routers introduce the potential for scaling issues. In general
a relay router should not attempt to serve more sites than any other
transit router, allowing for the encapsulation overhead.

Carpenter + Moore Expires December 1999 [Page 10]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

5.2.3 Unwilling to relay

It may arise that a site has a router with both 6to4 pseudo-
interfaces and native IPv6 interfaces, but is unwilling to act as a
relay router. Such a site MUST NOT advertise any {FP=001,TLA=TLA624} 2002:: prefix into
the native IPv6 realm and MUST NOT advertise any native IPv6 prefixes
or a default IPv6 route into the 6to4 realm. Within the 6to4 realm it
will behave exactly as in the pure basic 6to4 scenario of Section 5.1.

5.3 Variant scenario with tunnel to IPv6 space

A 6to4 site which has no v6 connections to the "native" IPv6 Internet
MAY
can acquire effective connectivity to the v6 Internet via a
"configured tunnel" (using the terminology in [RFC 1933]) to a
cooperating router which does have v6 access. RFC 1933 proposes that
such tunnels could be autoconfigured using a v4 anycast address, but
this is outside of the scope of this document. Alternatively a tunnel
broker can be used. This scenario would be suitable for a small
user-managed site.

5.4 Fragmented Scenarios

If there are multiple relay routers between native IPv6 and the 6to4
world, different parts of the 6to4 world will be served by different
relays. The only complexity that this introduces is in the scoping of
2010::/16 advertisements within the native IPv6 world. Like any
BGP4+ advertisements, their scope must be correctly defined by
routing policy to ensure that traffic to 2010::/16 follows the
intended paths.

If there are multiple IPv6 stubs all interconnected by 6to4 through
the global IPv4 Internet, this is a simple generalisation of the
basic scenarios of sections 5.1. and 5.2 and no new issues arise.

Carpenter + Moore Expires April 2000 [Page 11]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but only one of
|______|_______| 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, disjoint
IPv4 networks (i.e. a fragmented IPv4 world) then the 6to4 world is
also fragmented; this is the one scenario that must be avoided. It
is illustrated below to show why it does not work.
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but sites A and B
|______|_______| 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 |
|________| |________| |________| |________|

5.5 Multihoming

Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by
using a TLA624 2002:: prefix for each IPv4 border router, thereby
automatically obtaining a degree of IPv6 multihoming. The address
selection algorithm

Carpenter + Moore Expires April 2000 [Page 12]

Internet Draft Connection of the previous section will apply.

5.5 IPv6 Domains via IPv4 Clouds October 1999

5.6 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 a border router (or router plus IPv4 NAT)
connected to the external IPv4 network to support 6to4,
including advertising the appropriate TLA624 2002:: prefix locally.
Configure IPv6 DNS entries using this prefix. At this point
the 6to4 mechanism is automatically available, and the site
has obtained a "free" IPv6 prefix.

3. Identify a 6to4 relay router willing to relay the site's
traffic to the native IPv6 world. This could either be at
another cooperative 6to4 site, or an ISP service. Configure
a default IPv6 route to that relay router, and have the relay

Carpenter + Moore Expires December 1999 [Page 11]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

router configure a route to this site's 6to4 prefix.
an IPv6 routing protocol such as BGP4+ with it.

4. When native external IPv6 connectivity becomes available,
add a second (native) IPv6 prefix to both the border router
configuration and the DNS configuration. At this point, the an
address selection rule described above will determine when 6to4 and when
native IPv6 will be used.

5. When 6to4 usage is determined to have ceased (which may
be several years later), remove the 6to4 configuration.

5.6

5.7 Usage with firewall or NAT

The 6to4 mechanisms can run exactly as described above in appear to be unaffected by the presence of a
firewall at the border 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 NAT box must also contain a fully
finctional
functional IPv6 router including the 6to4 mechanism. The address used
for V4ADDR will simply be a globally unique IPv4 address allocated to
the NAT. In the example of Section 5.1 above, the 6to4 routers would
also be the sites' IPv4 NATs, which would own the 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 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.

Carpenter + Moore Expires April 2000 [Page 13]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

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 address this situation in detail. However, it can certainly be
handled by administrative sub-allocation of the TLA624 2002:: prefix
constructed from the global IPv4 address of the outermost NAT.

5.7

5.8 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 2002:: 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.

Carpenter + Moore Expires December 1999 [Page 12]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

5.8

5.9 Summary of impact on routing

IGP (site) routing will treat the local site's TLA624 /48 2002::/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 2002::/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 2002::/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,
{FP=001,TLA=0x0002,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.

Note that nothing except careful engineering can prevent incongruent
routing, in which the physical path followed by IPv6 traffic from A
to B is different from the physical path followed by IPv4 traffic.
By construction, unicast IPv6 traffic within a 6to4 domain will
follow exactly the same path as IPv4 traffic. However, multicast
traffic may follow an incongruent path, and when relay routers are in
use, paths will be congruent only if relay routers are positioned and
configured appropriately. This does not affect connectivity, but may
affect performance and operations.

Carpenter + Moore Expires April 2000 [Page 14]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

6. Multicast and Anycast

It is not possible to assume the general availability of wide-area
IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume
only unicast capability in its underlying IPv4 carrier network.
However, nothing prevents IPv6 multicast packets being sent to or
sourced from a 6to4 router encapsulated in IPv4 unicast packets
exactly as defined in Section 4. An IPv6 multicast routing protocol
MUST be used.

PIM needs a unicast routing protocol to provide the base for the RPF.
Thus 6to4 routers should assume they are directly attached to
<FP=001, TLA624>/16
2002::/16 prefix, i.e. they should inject such a unicast route into
their site for the purposes of multicast routing.

Similarly, 6to4 routers will use PIM among themselves (including
relay routers) to determine off-site multicast forwarding paths.

However, 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

Carpenter + Moore Expires December 1999 [Page 13]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999
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
2002:: prefixes.

7. ICMP messages

ICMP "unreachable" and other messages returned by the IPv4 routing
system will be returned to the 6to4 router that generated a
encapsulated TLA624 2002:: 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 beyond the special TLA value
TLA624 = 0x0010. [*** value to be confirmed ***]
0x0002 already assigned.

9. Security considerations

Implementors should be aware that, in addition to posssible attacks
against IPv6, security attacks against IPv4 must also be considered.

Carpenter + Moore Expires April 2000 [Page 15]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds October 1999

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 2002:: address. If this check is
applied, exceptions to it must be configured to admit traffic from
relay routers (Section 5). TLA624 2002:: traffic must also be excepted from
checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].

Carpenter + Moore Expires December 1999 [Page 14]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June 1999

Acknowledgements

The basic idea presented above is probably not original, and we have
had invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim
Bound, Randy Bush, Matt Crawford, Richard Draves, Joel Halpern, Tony
Hain, Bob Hinden, Geoff Huston, Thomas Narten, Erik Nordmark, Markku Savela,
Savela and other members of the NGTRANS working group. Special help was received from Joel Halpern. Some text has
been copied from [6OVER4]. George Tsirtsis kindly drafted two of the
diagrams.

Carpenter + Moore Expires December 1999 April 2000 [Page 15] 16]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 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

[API] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic
Socket Interface Extensions for IPv6", RFC 2553.

[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). RFC 2529.

[ANYCAST] Johnson, D. and Deering, S., Reserved IPv6 Subnet Anycast
Addresses, draft-ietf-ipngwg-resv-anycast-01.txt (work in progress).

[SELECT] Draves, R., Simple Source Address Selection for IPv6,
draft-draves-ipngwg-simple-srcaddr-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 Internet Division
iCAIR, Suite 150
1890 Maple Avenue
Evanston IL 60201, USA

Email: brian@icair.org

Keith Moore
Innovative Computing Laboratory
University of Tennessee
104 Ayres Hall

Carpenter + Moore Expires December 1999 April 2000 [Page 16] 17]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds June October 1999

University of Tennessee
104 Ayres Hall
Knoxville TN 37996, USA

Email: moore@cs.utk.edu

Intellectual Property

PLACEHOLDER for full IETF IPR Statement if needed.

Full Copyright Statement

PLACEHOLDER for full ISOC copyright Statement if needed.

Carpenter + Moore Expires December 1999 April 2000 [Page 17] 18]
----