[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3056

IETF                                                        B. Carpenter
Internet Draft                                                  K. Moore
June 2000



  Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels




                             Copyright Notice

                      Placeholder for ISOC copyright.



                                 Abstract

                      draft-ietf-ngtrans-6to4-06.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.
   Effectively it treats the IPv4 network as a unicast link layer. Note
   that this is not considered to be a long term solution and that sites
   should migrate in due course to native IPv6 prefixes.

   The motivation for this method is to allow isolated IPv6 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. 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 2000                  [Page 1]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   Table of Contents:

      Status of this Memo.............................................1
      0. Changes and Issues (RFC Editor: please remove before publication)3
      1. Introduction.................................................4
      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 prefixes8
      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..........................11
      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 Variant scenario with tunnel to IPv6 space.................13
      5.4 Fragmented Scenarios.......................................13
      5.5 Multihoming................................................15
      5.6 Transition considerations..................................15
      5.7 Coexistence with firewall, NAT or RSIP.....................15
      5.8 Usage within Intranets.....................................16
      5.9 Summary of impact on routing...............................16
      5.10. Routing loop prevention..................................17
      6. Multicast and Anycast.......................................17
      7. ICMP messages...............................................17
      8. IANA considerations.........................................18
      9. Security considerations.....................................18
      Acknowledgements...............................................18
      References.....................................................20
      Authors' Addresses.............................................21
      Intellectual Property..........................................21
      Full Copyright Statement.......................................21





















Carpenter + Moore        Expires December 2000                  [Page 2]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


0. Changes and Issues (RFC Editor: please remove before publication)

   Changes from 05 to 06 version:

   - wording clarification in section 5.2, clause 2.2
   - typographical errors corrected

   Changes from 04 to 05 version:

   - text on multicast largely removed (awaiting separate draft)
   - noted that relay routers only accept traffic from specific sites
   - clarified that V4ADDR must be configured on an IPv4 interface
   - link-local text rewritten
   - added note on NUD
   - strengthened security text on address filtering
   - general text clarifications and response to detail comments

   Changes from 03 to 04 version:

   - added terminology section
   - another revision of the address selection text
   - described link-local address formation
   - changed sending rule to refer to next hop
   - removed confusing text on IPv4 header padding
   - clarification/corrections to exterior routing discussion
   - clarified MTU text again
   - added section on routing loops
   - added and removed text on multicast
   - added text on RSIP
   - reformulated section on Intranet usage
   - general text clarifications and response to detail comments

   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




Carpenter + Moore        Expires December 2000                  [Page 3]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


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 specifies an encapsulation mechanism for
   transmitting IPv6 packets using such a prefix over the global IPv4
   network. Effectively it treats the wide area IPv4 network as a
   unicast point-to-point link layer.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. Also note that this is not considered
   to be a long term solution and that sites should migrate in due
   course to native IPv6 prefixes.

   Although the 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 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.

   IPv6 sites or hosts connected using this method do not require IPv4-
   compatible IPv6 addresses [MECH] 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 specific host modifications except a suggested
   address selection default. 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
   are not discussed in this 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].



1.1. Terminology

   The terminology of [IPV6] applies to this document.

   6to4 pseudo-interface. 6to4 encapsulation of IPv6 packets inside IPv4
   packets occurs at a point that is logically equivalent to an IPv6
   interface, with the link layer being the IPv4 unicast network. This
   point is referred to as a pseudo-interface. Some implementors may
   treat it exactly like any other interface and others may treat it
   like a tunnel end-point.


Carpenter + Moore        Expires December 2000                  [Page 4]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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 type
   of prefix than 6to4.

   6to4 router: an IPv6 router supporting a 6to4 pseudo-interface. It is
   normally the border router between an IPv6 site and a wide-area 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 a
   configured tunnel. Such a node may function as an IPv6 host using a
   6to4 address on its configured tunnel interface, and it may also
   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,
   therefore containing at least one 6to4 host and at least one 6to4
   router.

   Relay router: a 6to4 router configured to support transit routing
   between 6to4 addresses and native IPv6 addresses.

   6to4 exterior routing domain: a routing domain interconnecting a set
   of 6to4 routers and relay routers. It is distinct from an IPv6 site's
   interior routing domain, and distinct from all native IPv6 exterior
   routing domains.



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] for the 6to4 scheme.Its numeric value is 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: 0x0002
      NLA value: V4ADDR



Carpenter + Moore        Expires December 2000                  [Page 5]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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 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 according to the normal mechanisms
   such as [CONF, DISC], for native IPv6 routing, or for the "6over4"
   mechanism [6OVER4].



2.1 Address Selection

   To ensure the correct operation of 6to4 in complex topologies, source
   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 by
   the DNS for the destination host contains at least one 2002::
   address, then the source host must make an appropriate choice of the
   source and destination addresses to be used. The mechanisms for
   address selection in general are under study at the time of writing
   [SELECT]. Subject to those general mechanisms, the principle that
   will normally allow correct operation of 6to4 is this:

   If one host has only a 6to4 address, and the other one has both a
   6to4 and a native IPv6 address, then the 6to4 address should be used
   for both.

   If both hosts have a 6to4 address and a native IPv6 address, then
   either the 6to4 address should be used for both, or the native IPv6
   address should be used for both. The choice should be configurable.
   The default configuration should be native IPv6 for both.




3. Encapsulation in IPv4

   IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when
   they leave the site via its external IPv4 connection.  Note that the
   IPv4 interface that is carrying the 6to4 traffic is notionally
   equivalent to an IPv6 interface, and is referred to below as a
   pseudo-interface, although this phrase is not intended to define an
   implementation technique.  V4ADDR MUST be configured on the IPv4
   interface.

   IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
   protocol type of 41, the same as has been assigned [MECH] for IPv6
   packets that are tunneled inside of IPv4 frames.  The IPv4 header


Carpenter + Moore        Expires December 2000                  [Page 6]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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 5 for more details).  The IPv4 packet
   body contains the IPv6 header and payload.

        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 the
   encapsulated IPv6 hop limit [IPv6]. Other considerations are as
   described in Section 4.1.2 of [MECH].



3.1. Link-Local Address and NUD

   The link-local address of a 6to4 pseudo-interface performing 6to4
   encapsulation would, if needed, be formed as described in Section 3.7
   of [MECH].  However, no scenario is known in which such an address
   would be useful, since a peer 6to4 gateway cannot determine the
   appropriate link-layer (IPv4) address to send to.

   Neighbor Unreachability Detection (NUD) is handled as described in
   Section 3.8 of [MECH].



4. Maximum Transmission Unit

   MTU size considerations are as described for tunnels in [MECH].

   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.





Carpenter + Moore        Expires December 2000                  [Page 7]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


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
   records with the IPv6 prefix {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=0x0002,NLA=9.254.253.252}/48.

   When an IPv6 host on site B queries the DNS entry for a host on site
   A, or otherwise obtains its address, it obtains an address with the
   prefix {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.
                               _______________________________
                              |                               |
                              |  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, 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 6to4 router on each 6to4 site MUST
   include the following sending rule. Note that this rule refers to the
   next IPv6 hop that the packet will be sent to, which is not
   necessarily the final destination address.

   SENDING RULE

        if the next hop IPv6 address for an IPv6 packet is non-local


Carpenter + Moore        Expires December 2000                  [Page 8]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


           and its prefix is 2002::/16
           then
               apply any security checks (see Section 8);
               encapsulate the packet in IPv4 as in Section 3,
               with IPv4 destination address = the NLA value V4ADDR
               from the next hop IPv6 address;
               queue the packet for IPv4 forwarding.

   A simple decapsulation rule for incoming IPv4 packets with protocol
   type 41 MUST be implemented:

   DECAPSULATION RULE

          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
   special sending rule configured in the 6to4 router. This router
   SHOULD also generate the appropriate IPv6 prefix announcements [CONF,
   DISC].

   Although site A and site B will each need to run IPv6 routing
   internally, they do not need to run an IPv6 exterior routing protocol
   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 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-
   homed sites are discused in section 5.3.

   Because of the lack of configuration, and the distributed deployment
   model, there are believed to be no particular scaling issues with the
   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 IPv6

   During the transition to IPv6 we can expect some sites to fit the
   model just described (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 to these native IPv6 islands and
   vice versa.  In the 6to4 model, this connectivity is accomplished by
   IPv6 routers which support both 6to4 and native IPv6 addresses.


Carpenter + Moore        Expires December 2000                  [Page 9]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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 between the 6to4
   domain and a given native IPv6 domain.  There is nothing special
   about 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.

   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 interconnecting
       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 in
   section 5.1.

   2. There are two deployment options for a 6to4 exterior routing
   domain:

   2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using
   a given relay router each have a default IPv6 route pointing to the
   relay router. The relay router MAY apply source address based filters
   to accept traffic only from  specific 6to4 routers.

   2.2 An IPv6 exterior routing protocol is used. The set of 6to4
   routers using a given relay router obtain native IPv6 routes from the
   relay router using a routing protocol such as BGP4+ [RFC 2283,
   BGP4+]. The relay router will advertise whatever native IPv6 routing
   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 necessary for network operators to carefully consider
   desirable traffic patterns and topology when choosing the scope of
   such routing advertisements. The relay router will establish BGP
   peering only with specific 6to4 routers whose traffic it is willing
   to accept.

   Although this solution is more complex, it provides effective policy
   control, i.e. BGP4+ policy determines which 6to4 routers are able to
   use which relay router.

   3. A relay router MUST advertise a route to 2002::/16 into the native
   IPv6 exterior routing domain. It is a matter of routing policy how
   far this routing advertisement of 2002::/16 is propagated in the
   native IPv6 routing system. Since there will 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


Carpenter + Moore        Expires December 2000                 [Page 10]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   to potential unreachability or to perverse traffic patterns.

   A 6to4 site which also has a native IPv6 connection MUST NOT
   advertise its 2002::/48 routing prefix on that connection, and IPv6
   network operators MUST filter out and discard any 2002:: routing
   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 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).

   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.

             ____________________________         ______________________
            |                            |       |                      |
            |  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 multiple
   prefixes, it will simply send packets to an IPv6 address formed with
   the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is essential that
   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 mechanism 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.  A variant of this is for an Internet
   Service Provider, that already offers native 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,


Carpenter + Moore        Expires December 2000                 [Page 11]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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 may do so on its 6to4 pseudo-interface, but
   these are independent routing domains with separate policies, even if
   the same protocol, probably 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 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on
   that interface. Routing policy within the native IPv6 routing domain
   determines the scope of that advertisement, thereby limiting the
   visibility of the relay router in that domain.

   IPv6 packets received by the relay router whose next hop IPv6 address
   matches 2002::/16 will be routed to its 6to4 pseudo-interface and
   treated according to the sending rule of Section 51.



5.2.2.1. BGP4+ not used

   If BGP4+ is not deployed in the 6to4 exterior routing domain (option
   2.1 of Section 5.2), the relay router will be configured to accept
   and relay all IPv6 traffic only from its client 6to4 sites.  Each
   6to4 router served by the relay router will be configured with a
   default IPv6 route to the relay router (for example, Site A's default
   IPv6 route ::/0 would point to 2002:09fe:fdfc::/48).



5.2.2.2. BGP4+ used

   If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2
   of Section 5.2), the relay router advertises IPv6 native routing
   prefixes on its 6to4 pseudo-interface, peering only with the 6to4
   routers that it serves.  (An alternative is that these routes could
   be advertised along with IPv4 routes using BGP4 over IPv4, rather
   than by running a separate BGP4+ session.)  The specific routes
   advertised depend on applicable routing policy, but they must be
   chosen from among those reachable through the relay router's native
   IPv6 interface. In the simplest case, a default route to the whole
   IPv6 address space could be advertised. When multiple relay routers
   are in use, more specific routing prefixes would be advertised
   according to the desired routing policy. The usage of BGP4+ is
   completely standard so is not discussed further in this document.




Carpenter + Moore        Expires December 2000                 [Page 12]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


5.2.2.3. Relay router scaling

   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.



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 2002:: routing
   prefix into the native IPv6 domain and MUST NOT advertise any native
   IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.
   Within the 6to4 domain it will behave exactly as in the basic 6to4
   scenario of Section 5.1.



5.3 Variant scenario with tunnel to IPv6 space

   A 6to4 site which has no IPv6 connections to the "native" IPv6
   Internet can acquire effective connectivity to the v6 Internet via a
   "configured tunnel" (using the terminology in [MECH]) to a
   cooperating router which does have IPv6 access, but which does not
   need to be a 6to4 router. Such tunnels could be autoconfigured using
   an IPv4 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.

   These mechanisms are not described in detail in this document.



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
   2002::/16 routing advertisements within the native IPv6 world.  Like
   any BGP4+ advertisements, their scope must be correctly defined by
   routing policy to ensure that traffic to 2002::/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.
   This is shown in the following figure. Subject to consistent
   configuration of routing advertisements, there are no known issues
   with this scenario.






Carpenter + Moore        Expires December 2000                 [Page 13]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


                    ______________
                   |     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, since the
   2002::/16 advertisement from Relay1 will be invisible to Relay2, and
   vice versa. Sites A and B therefore have no connectivity to sites C
   and D.
                    ______________
                   |     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 |
    |________|  |________|  |________|  |________|










Carpenter + Moore        Expires December 2000                 [Page 14]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


5.5 Multihoming

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



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 2002:: routing 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. If no exterior
   routing protocol is in use in the 6to4 exterior routing domain,
   the site's 6to4 router will be configured with a default IPv6
   route pointing to that relay router's 6to4 address. If an exterior
   routing protocol such as BGP4+ is in use, the site's 6to4 router
   will be configured to establish appropriate BGP peerings.

   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, an
   address selection rule 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.7 Coexistence with firewall, NAT or RSIP

   The 6to4 mechanisms 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
   functional IPv6 router including the 6to4 mechanism. The address used


Carpenter + Moore        Expires December 2000                 [Page 15]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   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.

   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 2002: prefix
   constructed from the global IPv4 address of the outermost NAT.

   The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with
   6to4. If a 6to4 border router is combined with an RSIP border router,
   it can support IPv6 hosts using 6to4 addresses, IPv4 hosts using
   RSIP, or dual stack hosts using both. The RSIP function provides
   fine-grained management of dynamic global IPv4 address allocation and
   the 6to4 function provides a stable IPv6 global address to each host.
   As with NAT, the IPv4 address used to construct the site's 2002:
   prefix will be one of the global addresses of the RSIP border router.



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 2002:: prefixes.  The V4ADDR MUST be
   a duly allocated global IPv4 address, which MUST be unique within the
   private network. The Intranet thereby obtains globally unique IPv6
   addresses even if it is internally using private IPv4 addresses [RFC
   1918].



5.9 Summary of impact on routing

   IGP (site) routing will treat the local site's 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 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 2002::/16
   prefix from relay routers into the native IPv6 domain, whose scope is
   limited by routing policy. This is the only non-native IPv6 prefix
   advertised by BGP.



Carpenter + Moore        Expires December 2000                 [Page 16]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   It will be necessary for 6to4 routers to obtain routes to relay
   routers in order to access the native IPv6 domain. In the simplest
   case there will be a manually configured default IPv6 route to
   {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address
   of a relay router. Such a route could be used to establish a BGP
   session for the exchange of additional IPv6 routes.

   By construction, unicast IPv6 traffic within a 6to4 domain will
   follow exactly the same path as unicast IPv4 traffic.



5.10. Routing loop prevention

   Since 6to4 has no impact on IPv4 routing, it cannot induce routing
   loops in IPv4. Since 2002: prefixes behave exactly like standard IPv6
   prefixes, they will not create any new mechanisms for routing loops
   in IPv6 unless misconfigured. One very dangerous misconfiguration
   would be an announcement of the 2002::/16 prefix into a 6to4 exterior
   routing domain, since this would attract all 6to4 traffic into the
   site making the announcement. Its 6to4 router would then resend non-
   local 6to4 traffic back out, forming a loop.

   The 2002::/16 routing prefix may be legitimately advertised into the
   native IPv6 routing domain by a relay router, and into an IPv6 site's
   local IPv6 routing domain; hence there is a risk of misconfiguration
   causing it to be advertised into a 6to4 exterior routing domain.

   To summarise, the 2002::/16 prefix MUST NOT be advertised to a 6to4
   exterior routing domain.



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.  An
   IPv6 multicast routing protocol is needed, and will be the subject of
   a future document.

   The allocated anycast address space [ANYCAST] is compatible with
   2002:: prefixes, i.e. anycast addresses formed with such prefixes may
   be used inside a 6to4 site.



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


Carpenter + Moore        Expires December 2000                 [Page 17]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   layer for IPv6 operational purposes. Other considerations are as
   described in Section 4.1.3 of [MECH].



8. IANA considerations

   No assignments by the IANA are required beyond the special TLA value
   0x0002 already assigned.



9. Security considerations

   Implementors should be aware that, in addition to possible 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 likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied. A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address. If this check is
   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).  2002:: traffic must also be excepted from
   checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].

   In any case, any 6to4 traffic whose source or destination address
   embeds a V4ADDR which is not in the format of a global unicast
   address MUST be silently discarded by both encapsulators and
   decapsulators. Specifically, this means that IPv4 addresses defined
   in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
   addresses are unacceptable.




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, Jun-ichiro itojun
   Hagino, Joel Halpern, Tony Hain, Andy Hazeltine, Bob Hinden, Geoff
   Huston, Perry Metzger, Thomas Narten, Erik Nordmark, Markku Savela,
   Ole Troan, Sowmini Varadhan, members of the Compaq IPv6 engineering
   team, and other members of the NGTRANS working group. Some text has


Carpenter + Moore        Expires December 2000                 [Page 18]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


   been copied from [6OVER4]. George Tsirtsis kindly drafted two of the
   diagrams.























































Carpenter + Moore        Expires December 2000                 [Page 19]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


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.

   [BGP4+] Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
   Routing. P. Marques, F. Dupont, RFC 2545

   [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", 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., Default Address Selection for IPv6, draft-ietf-
   ipngwg-default-addr-select-00.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

   [MECH] Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan
   & E. Nordmark, draft-ietf-ngtrans-mech-06.txt (work in progress
   updating RFC 1933).

   [RSIP] Realm Specific IP: Protocol Specification, M. Borella, D.
   Grabelsky, J. Lo, K. Tuniguchi, draft-ietf-nat-rsip-protocol-03.txt
   (work in progress)

   [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels.
   S. Bradner, RFC 2119

   [RFC 2283] Multiprotocol Extensions for BGP-4, T. Bates, R. Chandra,
   D. Katz, Y. Rekhter, RFC 2283







Carpenter + Moore        Expires December 2000                 [Page 20]

Internet Draft Connection of IPv6 Domains via IPv4 Clouds      June 2000


Authors' Addresses


      Brian E. Carpenter
      IBM
      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
      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 2000                 [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/