IETF                                              B. Carpenter, IBM
Internet Draft                                        C. Jung, 3Com
September 1997



    Transmission of IPv6 over IPv4 Domains without Explicit Tunnels


                    draft-carpenter-ipng-6over4-03.txt
    


Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   This memo specifies the frame format for transmission of IPv6 [IPV6]
   packets and the method of forming IPv6 link-local addresses over IPv4
   domains.  It also specifies the content of the Source/Target Link-
   layer Address option used in the Router Solicitation, Router
   Advertisement, Neighbor Solicitation, and Neighbor Advertisement
   and Redirect messages, when those messages are transmitted on an
   IPv4 network.
 
   The motivation for this method is to allow isolated IPv6 hosts,
   located on a physical link which has no directly connected IPv6
   router, to become fully functional IPv6 hosts by using an IPv4
   domain, preferably supporting IPv4 multicast, as their virtual local
   link.
 
   Originally submitted to the IPNG WG, this draft will be discussed in
   the NGTRANS WG, ngtrans[-request]@sunroof.Eng.Sun.COM.
 
 


Carpenter, Jung                Expires March 1998               [Page 1]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


Table of Contents:

   1. Introduction....................................................2
   2. Maximum Transmission Unit.......................................3
   3. Frame Format....................................................3
   4. Stateless Autoconfiguration and Link-Local Addresses............4
   5. Address Mapping -- Unicast......................................4
   6. Address Mapping -- Multicast....................................5
   7. Mechanism in the absence of IPv4 multicast......................5
   8. Scaling and Transition Isues....................................5
   9. Security considerations.........................................6
   Acknowledgements...................................................7
   References.........................................................7
   Authors' Addresses.................................................7
   APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8



1. Introduction

   This memo specifies the frame format for transmission of IPv6 [IPV6]
   packets and the method of forming IPv6 link-local addresses over IPv4
   "domains".  For the purposes of this document, an IPv4 domain is a
   fully interconnected set of IPv4 subnets on which there is at least
   one IPv6 router and at least one IPv6 host conforming to this
   specification.  This IPv4 domain could form part of the globally-
   unique IPv4 address space, or could form part of a private IPv4
   network [RFC 1918].

   This memo also specifies the content of the Source/Target Link-layer
   Address option used in the Router Solicitation, Router Advertisement,
   Neighbor Solicitation, Neighbor Advertisement and Redirect messages 
   described in [DISC], when those messages are transmitted on an IPv4 
   domain.

   The motivation for this method is to allow isolated IPv6 hosts,
   located on a physical link which has no directly connected IPv6
   router, to become fully functional IPv6 hosts by using an IPv4 domain
   as their virtual local link.  Thus, at least one IPv6 router using
   the same method must be connected to the same IPv4 domain if IPv6
   routing to other links is required.

   IPv6 hosts connected using this method do not require IPv4-compatible
   addresses or configured tunnels.  In this way IPv6 gains considerable
   independence of the underlying links and can step over many hops of
   IPv4 subnets.






Carpenter, Jung                Expires March 1998               [Page 2]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


2. Maximum Transmission Unit

   The default MTU size for IPv6 packets on an IPv4 domain is 1480
   octets.  This size may be varied by a Router Advertisement [DISC]
   containing an MTU option which specifies a different MTU, or by
   manual configuration of each node.

   Note that if by chance the IPv6 MTU size proves to be too large for
   some intermediate IPv4 subnet, IPv4 fragmentation will ensue.  While
   undesirable, this is not disastrous.

3. Frame Format

   IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
   protocol type of 41, the same as has been assigned in RFC 1933 for
   IPv6 packets that are tunneled inside of IPv4 frames.  The IPv4
   header contains the Destination and Source IPv4 addresses.  The IPv4
   packet body contains the IPv6 header followed immediately by the
   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 ...              /
    +-------+-------+-------+-------+-------+------+------+


   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 Time to Live field SHOULD be set to a low value, to prevent such
   packets accidentally leaking from the IPv4 domain.  This MUST be a
   configurable parameter, with a recommended default of 8.





Carpenter, Jung                Expires March 1998               [Page 3]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


4. Stateless Autoconfiguration and Link-Local Addresses

   The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit 
   IPv4 address of that interface, with the octets in the same order in 
   which they would appear in the header of an IPv4 packet, padded at 
   the left with zeros to a total of 64 bits.  Note that the "Universal/
   Local" bit is zero, indicating that the Interface Identifer is not 
   globally unique.  When the host has more than one IPv4 address in use 
   on the physical interface concerned, an administrative choice of one 
   of these IPv4 addresses is made.

   An IPv6 address prefix used for stateless autoconfiguration of an
   IPv4 interface must have a length of 64 bits. 

   The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is
   formed by appending the Interface Identifier, as defined above, to 
   the prefix FE80::/64.

    +-------+-------+-------+-------+-------+-------+------+------+
    |  FE      80      00      00      00      00      00     00  |
    +-------+-------+-------+-------+-------+-------+------+------+
    |  00      00   |  00   |  00   |   IPv4 Address              |
    +-------+-------+-------+-------+-------+-------+------+------+


5. Address Mapping -- Unicast

   The procedure for mapping IPv6 addresses into IPv4 virtual link-layer
   addresses is described in [DISC].  The Source/Target Link-layer
   Address option has the following form when the link layer is IPv4.
   Since the length field is in units of 8 bytes, the value below is 1.

    +-------+-------+-------+-------+-------+-------+-------+-------+
    | Type  |Length | must be zero  |        IPv4 Address           |
    +-------+-------+-------+-------+-------+-------+-------+-------+


   Type:
    1 for Source Link-layer address.
    2 for Target Link-layer address.

   Length:
    1 (in units of 8 octets).

   IPv4 Address:

   The 32 bit IPv4 address, in network byte order.  This is the address
   the interface currently responds to, and may be different from the
   Interface Identifier for stateless autoconfiguration.



Carpenter, Jung                Expires March 1998               [Page 4]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


6. Address Mapping -- Multicast

   If IPv4 multicast is available, an IPv6 packet with a multicast
   destination address DST MUST be transmitted to the IPv4 multicast
   address of Organization-Local Scope using the mapping below.  These
   IPv4 multicast addresses are taken from the block 239.192.0.0/16, a
   a sub-block of the Organization-Local Scope address block, or, if 
   all of those are not available, from either of the expansion blocks 
   239.128.0.0/10 or 239.64.0.0/10.  Note that when they are formed 
   using the expansion blocks, they use only a /16 sized block.

        +-------+-------+-------+-------+       
        |  239  |  OLS  | DST14 | DST15 |
        +-------+-------+-------+-------+

        DST14, DST15        last two bytes of IPv6 multicast address.

        OLS                 from the configured Organization-Local
                            Scope address block.  It is one of 192,
                            128 or 64.  See [ADMIN] for details.


   See appendix A. for a list of all the multicast groups that must be
   joined to support Neighbor Discovery.


7. Mechanism in the absence of IPv4 multicast

   It is strongly recommended to use IPv4 multicast as described above,
   and this MUST be the default configuration in implementations.
   However, if the IPv4 domain does not support IPv4 multicast, a
   unicast technique is used.

   In this case the IPv6 router MUST handle IPv6 multicast packets by
   replication to all tunnels required to reach the relevant IPv6 
   destinations (i.e., all those that have joined the IPv6 multicast 
   group), since the mapping onto an IPv4 multicast address is not
   available.


8. Scaling and Transition Isues

   The multicast mechanism described in Section 6 above appears to have
   essentially the same scaling properties as native IPv6 over most
   media, except for the slight reduction in MTU size which will
   slightly reduce bulk throughput.  On an ATM network, where IPv4
   multicast relies on relatively complex mechanisms, it is to be





Carpenter, Jung                Expires March 1998               [Page 5]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


   expected that IPv6 over IPv4 over ATM will perform less well than
   native IPv6 over ATM.

   The standard tunnel mechanism described in Section 8, if used to
   support IPv6 multicast, will not scale well and should be used only
   for a small number of IPv6 hosts.  For IPv6 unicast traffic, it will
   have similar scaling properties to configured tunnels.

   The IPv6 over IPv4 mechanism is intended to take its place in the
   range of options available for transition from IPv4 to IPv6.  In
   particular it allows a site to run both IPv4 and IPv6 in coexistence,
   without having to configure IPv6 hosts either with IPv4-compatible
   addresses or with tunnels.  Interfaces of the IPv6 router and hosts
   will of course need to be enabled in "IPv6 over IPv4" mode.

   A site may choose to start its IPv6 transition by configuring one
   IPv6 router to support "IPv6 over IPv4" on an interface connected to
   the site's IPv4 domain, and another IPv6 format on an interface
   connected to the IPv6 Internet.  Any enabled "IPv6 over IPv4" hosts
   in the IPv4 domain will then be able to communicate both with the
   router and with the IPv6 Internet, without manual configuration of a
   tunnel and without the need for an IPv4-compatible IPv6 address,
   either stateless or stateful address configuration providing the IPv6
   address to the IPv6 host.

   As the site installs additional IPv6 routers, "IPv6 over IPv4" hosts
   which become physically adjacent to IPv6 routers can be changed to
   run as native IPv6 hosts, with the the only impact on IPv6
   applications being a slight increase in MTU size.


9. Security considerations

   This specification introduces no known new security risks.  However,
   implementors should be aware that, in addition to posssible attacks
   against IPv6, security attacks against IPv4 must also be considered.

   Use of IP security at both IPv4 and IPv6 levels should nevertheless
   be avoided, for efficiency reasons.  For example, if IPv6 is running
   encrypted, encryption of IPv4 would be redundant except if traffic
   analysis is felt to be a threat.  If IPv6 is running authenticated,
   then authentication of IPv4 will add little.  Conversely, IPv4
   security will not protect IPv6 traffic once it leaves the IPv6-over-
   IPv4 domain.  Therefore, implementing IPv6 security is required even
   if IPv4 security is available.







Carpenter, Jung                Expires March 1998               [Page 6]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


Acknowledgements

   The basic idea presented above is not original, and we have had
   invaluable comments from Matt Crawford, Steve Deering, Dan
   Harrington, and members of the IPNG and NGTRANS working groups.
   This document is seriously ripped off from RFC 1972 written by
   Matt Crawford.


References

   [AARCH]    Hinden, R., and S. Deering, "IP Version 6 Addressing
              Architecture", currently draft-ietf-ipngwg-addr-arch-v2-
              02.txt

   [CONF]     Thomson, S., and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 1971

   [DISC]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 1970

   [IPV6]     Deering, S., and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883

   [RFC 791]  Postel, J., "Internet Protocol"

   [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
              Lear, E., "Address Allocation for Private Internets",
              RFC 1918


Authors' Addresses


      Brian E. Carpenter
      Internet Division
      IBM United Kingdom Laboratories
      MP 185, Hursley Park
      Winchester, Hampshire S021 2JN, UK

      Email: brian@hursley.ibm.com


      Cyndi Jung
      3Com Corporation
      5400 Bayfront Plaza, Mailstop 3219
      Santa Clara, California  95052-8145

      Email: cmj@3Com.com



Carpenter, Jung                Expires March 1998               [Page 7]


Internet Draft   Transmission of IPv6 Packets over IPv4   September 1997


APPENDIX A:  IPv4 Multicast Addresses for Neighbor Discovery

   The following IPv4 multicast groups are used to support Neighbor
   Discovery with this specification.

   all-nodes multicast address
         - the administratively-scoped IPv4 multicast address used to 
           reach all nodes in the local IPv4 domain supporting this 
           specification.  239.OLS.0.1

   all-routers multicast address
         - the administratively-scoped IPv4 multicast address to reach 
           all routers in the local IPv4 domain supporting this 
           specification.  239.OLS.0.2

   solicited-node multicast address
         - an administratively scoped multicast address that is computed 
           as a function of the solicited target's address by taking the 
           IPv4 address used to form the IPv6 address and prepending the 
           96-bit prefix FF02:0:0:0:0:1.  This is then mapped to the IPv4 
           multicast address in the method described in this document.  
           For example, if the IPv4 address used to form the IPv6 address 
           is W.X.Y.Z, then the IPv6 solicited node multicast address is 
           FF02::1:W.X.Y.Z and the corresponding IPv4 multicast address is 
           239.OLS.Y.Z



























Carpenter, Jung                Expires March 1998               [Page 8]