[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Internet Draft                                         Nathan Lutchansky
<draft-lutchann-ipv6-intro-00.txt>                    Cornell University
Expires: November 2001                                          May 2001


                    A Technical Introduction to IPv6

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.

Abstract

   This document attempts to provide an introduction to each of the new
   features of the Internet Protocol, version 6 (IPv6), including
   transitional mechanisms for interoperating in a mixed IPv4/IPv6
   environment.

1. Introduction

   After over five years of discussion and development, IPv6 is finally
   coming into production use. The 6bone, a testbed tunneled IPv6
   backbone, has been around for some time and is in experimental use by
   almost all major backbone providers. Several Internet exchanges are
   supporting IPv6 natively, including the London, Tokyo, and Chicago
   exchanges. ISPs in Australia and Japan are even beginning to offer
   native IPv6 service to their customers.

   Although the IPv6 protocol has been designed to minimize
   incompatibilities during the transition from IPv4, the current
   Internet Protocol, there are many enhancements and changes of which
   users and network administrators need to be aware.



Lutchansky                                                      [Page 1]


Internet Draft      A Technical Introduction to IPv6            May 2001


   Because IPv6 is still mostly an experimental protocol, this document
   is targeted at individuals having prior experience with TCP/IP who
   are interested in learning about IPv6 and its current state of
   development.  A solid knowledge of IP addressing, network topology,
   and local network routing is recommended, as well as a vague
   understanding of how routing operates on the Internet at large.
   Readers without experience with these concepts should become familiar
   with TCP/IP before beginning experimentation with IPv6.

2. The History of the Internet

   The primary motivation for revamping IP was the realization that the
   addressing scheme of IPv4 didn't provide enough addresses for all the
   computers and networks that are on the Internet today.

2.1. In the beginning...

   When the network was first created, sites on the Internet created
   network links directly to each other, and large blocks of addresses
   were assigned to each institution. For example, Stanford, like many
   of the first Internet sites, was allotted all addresses having a
   certain first octet of the IP address (36 for Stanford) --- only the
   first 8 bits of the IP address were needed to know that a packet was
   destined for the Stanford network. Although it seems wasteful and
   short-sighted in retrospect, it was actually the most intelligent way
   to design the network. By aggregating each site behind a large
   subnet, only one route in every router on the Internet was needed for
   each institution, regardless of whether the institution had 10
   computers, or 16 million.

   Three designations were made: "Class A" networks would have an 8-bit
   address to designate the destination network (like Stanford), "Class
   B" networks with a 16-bit network address, and "Class C" networks
   with a 24-bit network address.  The 32-bit IP address divided into
   the network address and the node address, thus Class A networks had
   24 bits worth of addresses available for the site topology, and Class
   C networks had 8 bits available.  Larger sites needing more addresses
   would be assigned a Class A or B block and smaller sites would be
   assigned a Class C block.

   ISPs didn't exist back then, so each site maintained its connection
   to the Internet by keeping a direct link to another connected
   institution.  The global routing tables only contained one route per
   institution, which was expected to be a total of a few hundred or
   thousand routes at most. There was no concern that the address space
   would be depleted; after all, the addressing scheme allowed for about
   60 large institutions with Class A networks and about 65000 smaller
   institutions with Class B networks. For a network that was only



Lutchansky                                                      [Page 2]


Internet Draft      A Technical Introduction to IPv6            May 2001


   intended to be used by universities and government researchers in the
   United States, surely this would be enough!

2.2. The Internet today

   Obviously, the Internet has grown larger than what the original
   designers expected. In the U.S. alone, virtually every educational
   institution, government office, and business has Internet access, as
   do most homes with a personal computer. Sites no longer have direct
   connections to each other but instead buy their Internet service from
   an ISP, who in turn pays for connectivity to a national or
   international backbone provider. Internet routing is no longer a web
   of connections, but more of a hierarchy, with the backbones on top,
   ISPs in the middle, and end users at the bottom. Keeping track of
   address assignments and routing information on the Internet has
   become a logistical nightmare.

   As a result of the explosive growth of the Internet, sites were no
   longer allowed to be assigned large blocks of addresses. To allow for
   more granularity in address assignments, the Class system was
   replaced with Classless Interdomain Routing (CIDR) which allows
   address blocks to be assigned on any bit boundary.

2.3. Classless Interdomain Routing

   One benefit of CIDR is that address blocks can be assigned in sizes
   that more accurately reflect a site's expected usage, but the more
   important effect is that the Internet routing architecture can now
   take advantage of the hierarchical structure of the Internet.  Larger
   address blocks (around 16 bits) are assigned to ISPs, who break down
   their allocation into smaller blocks (18-24 bits) which they assign
   to their customers' sites.

   As a result, the networks of many customers of an ISP can be
   aggregated into a single routing entry (a method called "route
   aggregation") in the global routing tables, since all packets to
   those networks are routed through that ISP, and only the ISP needs to
   know more specific routes for each customer. Thus, global routing
   tables need only contain entries for the address blocks of backbones
   and large ISPs.  In practice, however, multihomed sites (those with
   service from more than one ISP) each need to have one global route
   per ISP. Even with CIDR and route aggregation, global routing tables
   still contain over 100,000 entries!

   While the introduction of CIDR prevented routing tables from becoming
   unmanageably large and allowed the address space to be assigned in a
   more conservative manner, it created a different IP address problem.




Lutchansky                                                      [Page 3]


Internet Draft      A Technical Introduction to IPv6            May 2001


2.4. The pain of renumbering

   Since IP address blocks were initially intended to be assigned to
   sites rather than to ISPs, IP addresses assigned to individual
   computers and network devices were not expected to change often, if
   ever. Under CIDR, IP addresses used by a site must be allocated from
   the block owned by their ISP. This means that if a site switches
   their Internet service to a different ISP, they cannot continue to
   use the same IP addresses and must use new addresses assigned by the
   new ISP. Unfortunately, IPv4 wasn't designed to accommodate IP
   address changes, and so most TCP/IP stacks need to be reconfigured
   manually to change the IP address of a device, which often requires
   restarting the device. Changing ISPs can be a huge administrative
   headache for many sites.

3. Architectural changes in IPv6

   It was clear that a radical change needed to take place to ensure
   future growth of the Internet. IPv6 was designed with the goal of
   aggressive address aggregation, ideally restricting the global
   routing tables to contain only around 8,000 entries -- a tenth of
   today's size -- at the worst. In addition, IPv6 devices are required
   to automatically configure themselves for new IP addresses (a process
   called renumbering) for a seamless and low-overhead transition to a
   new ISP. Procedures for allocating address blocks for new IPv6
   addresses are very conservative to reduce wasted space.

3.1. Benefits of aggregation

   Route aggregation works well when each address can only be reached
   via one path, but multihomed sites with more than one ISP can be
   reached by multiple routes. In IPv4, routes to such sites need to be
   propagated through the global routing tables to ensure optimal,
   fault-tolerant routing. This practice is a contributor to the large
   size of the global routing tables and thus has been prohibited in
   IPv6.

   Through aggregation, IPv6 eliminates site-specific routes from global
   routing tables, so multihomed sites must be supported through other
   means. Two methods are available for multihomed sites to receive
   service from all of their providers.

3.2. Multihoming in IPv6

   A site may chose to designate one of their providers as a "primary"
   provider, and use only an IP address allocation from that provider.
   The remaining provider would accept the site's traffic directly from
   the primary, for load-sharing and to provide an alternate route to



Lutchansky                                                      [Page 4]


Internet Draft      A Technical Introduction to IPv6            May 2001


   the site in the event of a link outage between the site and the
   primary.  Outbound traffic could be sent from the site to either
   provider. This method requires that all providers to a multihomed
   site work together to provide service to the site.

   Alternatively, multihomed sites can be assigned an address block from
   each provider, and every device at the site would have one IP address
   per provider. For example, if a site obtains service from three ISPs,
   each device will be assigned three IP addresses to use. Optimal
   routing is achieved by using a complex set of source address
   selection rules for each outgoing connection. Fault tolerance is
   achieved by listing all the IP addresses for servers in DNS records,
   allowing clients outside the network to attempt connections to each
   address until successful.

   Each method has disadvantages, and multihoming in IPv6 is still a
   subject of discussion for the IETF.

3.3. Other IPv6 features

   In addition to enhanced addressing capabilities, IPv6 also
   incorporates a number of extensions that have been developed for
   IPv4. One of the more appealing IPv4 extensions now standard in IPv6
   is multicasting, which allows a data stream to be sent to the network
   only once and received by any number of interested hosts. Hopefully,
   multicasting will enable rich multimedia content to be streamed live
   over the Internet without the need for the massive bandwidth
   currently necessary to send one copy of the data to each recipient.
   Other standard IPv6 features include automatic configuration, a
   Quality of Service mechanism, and encryption capabilities (with
   IPSEC). IPv6 also has a capability to attach arbitrary header data to
   IP packets, allowing for extensions that may be developed in the
   future.

4. Basic IPv6 address format

   The IPv6 addressing architecture is described in [RFC-2373].

4.1. String format of addresses

   IPv6 extends the address size from 32 bits to 128 bits. Addresses are
   represented as hex numbers, with colons between every 16-bit chunk,
   e.g.  3ffe:23:9091:7e2:1:ff3b:c0a:11a0. Long strings of chunks of
   value zero can be replaced with a double colon, although only one
   double-colon can be present in an address. For example,
   3ffe:23:9091:0:0:0:0:1 can be written as 3ffe:23:9091::1. When
   writing IPv6 addresses in URLs, the address must be enclosed in
   square brackets, as per [RFC-2732]. For example, if the web server



Lutchansky                                                      [Page 5]


Internet Draft      A Technical Introduction to IPv6            May 2001


   WWW.DOM.AIN had the fictional IP address listed above, the site
   http://www.dom.ain/ would also be accessable at the URL
   http://[3ffe:23:9091::1]/. Note that the use of IPv6 addresses in
   URLs and other location identifiers is strongly discouraged, since IP
   addresses are expected to change often. Domain names should be used
   for this purpose instead.

4.2. Components of an IPv6 address

   Like IPv4 addresses, IPv6 addresses are broken into a network
   component and a node component. IPv6 takes the process one step
   further and breaks the network component into several pieces, each of
   which is used for routing at a different level of the Internet.
   [RFC-2374] defines a global aggregatable address format for IPv6
   unicast addresses.  Here is the format of the 128 bits of IPv6
   addresses, as described by that document:

   +--------+---------+--------+---------+---------+--------------+
   | 3 bits | 13 bits | 8 bits | 24 bits | 16 bits |   64 bits    |
   |   FP   | TLA ID  |  RSVD  | NLA ID  | SLA ID  | Interface ID |
   +--------+---------+--------+---------+---------+--------------+

   FP is the 3-bit format prefix, which defines the type of address.
   Addresses with the FP bits set to 001 will always follow the format
   described here.

   The 13-bit Top-Level Aggregation (TLA) identifier identifies the
   exchange or backbone provider that routes that address from the top
   level of the Internet -- so-called "default-free" zones.

   The 8-bit Reserved field (RSVD) should always be set to zero for now,
   at least in global unicast addresses. In the future, these bits will
   be used to expand the TLA or NLA fields as necessary.

   The 24-bit Next-Level Aggregation (NLA) identifier is split into
   further aggregation fields and a site identifier, as seen fit by each
   organization assigned a TLA ID. Portions of the NLA space may be
   suballocated to other organizations by the TLA holder. However, the
   top 48 bits of an IPv6 address must uniquely and fully identify a
   single site. This hard restriction on the site prefix boundary
   provides consistency between sites and allows organizations to switch
   ISPs without having to reorganize their site's topology.

   The 16-bit Site-Level Aggregation (SLA) identifier identifies
   individual subnets within an organization. Since the 16-bit length of
   the SLA identifier allows for 65,536 different subnets, it is
   unlikely that many organizations would need more than a single 48-bit
   prefix for a site.



Lutchansky                                                      [Page 6]


Internet Draft      A Technical Introduction to IPv6            May 2001


   The 64-bit Interface ID, unique to each host on a network, can either
   be set manually or can be automatically derived from the host's
   hardware address.

4.3. Address configuration and assignment

   IPv6 has several techniques for configuring the IP addresses of each
   host.  Of course, network administrators can manually assign
   interface IDs, and while this may be desirable for servers, it
   quickly becomes tedious when configuring and maintaining
   workstations.  Thus, several methods of automatic configuration are
   available.

   One method of automatic configuration is DHCPv6, which is specified
   in [DHCPv6], operates very similarly to DHCP in IPv4.

   IPv6 also allows for stateless automatic configuration for selecting
   interface IDs, allowing network devices to configure themselves on
   the network using only advertisement messages from routers as
   described in section 6 on Neighbor Discovery.  Devices learn the
   network prefix(es) from the routers on the network, then use a
   globally-unique interface ID in IEEE EUI-64 format which is usually
   generated from the hardware address of the network interface
   hardware. The EUI-64 format is described in detail in [RFC-2373].

4.4. Temporary addresses for privacy

   Because of privacy concerns involved in using a globally-unique
   identifier in an IP address, [RFC-3041] suggests the use of a
   secondary IP address containing a randomly-generated bitstring as the
   interface ID. Outgoing connections to public services use the random
   IP address, and incoming connections use the IP address obtained
   through manual or automatic configuration as described above. At this
   point, the privacy mechanism is not yet implemented, but it could
   potentially offer a greater degree of privacy than current IPv4
   address-assignment methods depending on the topology of the
   intervening network.

5. Other address conventions

5.1. Address prefixes

   Prefixes are used to define blocks of network addresses. They are
   written as an IP address followed by a slash and a prefix length,
   which indicates the number of bits which identify the network. This
   is similar to IPv4 CIDR notation. Since a double-colon (::) can be
   used to replace a number of zeros in an address, prefixes often end
   in :: to fill the unused address bits in a prefix with zeros. For



Lutchansky                                                      [Page 7]


Internet Draft      A Technical Introduction to IPv6            May 2001


   example, 3ffe::/16 describes all addresses beginning with the 16-bit
   string 3ffe and 2001:10::/48 describes all addresses beginning with
   the 48-bit string 2001:0010:0000.

5.2. Non-global addresses

   Two prefixes are set aside for link-local and site-local addresses.
   Link-Local Addresses, in prefix fe80::/64, are valid and unique only
   on the local network directly connected to each interface card
   (usually the local Ethernet segment) and are never routed. They are
   automatically assigned to every interface and are primarily used to
   obtain configuration information. Site-Local Addresses, in prefix
   fec0::/48, may be used however a site sees fit, and the IP addresses
   may be assigned to networks just like any global address allocation.
   Site-local addresses are never routed onto the Internet.

5.3. The loopback address

   The special address ::1 is the loopback address, which always points
   to the local machine. It is analogous to the 127.0.0.1 address in
   IPv4.

5.4. IPv4-compatible addresses

   Every IPv4 address can be written in IPv6 notation by appending 96
   bits of zeros to the beginning of the address, extending the address
   size to 128 bits, as shown here:

   +---------+--------------+
   | 96 bits |    32 bits   |
   |    0    | IPv4 address |
   +---------+--------------+

   These addresses are IPv4-compatible IPv6 addresses, formed by
   appending a double-colon to the beginning of a standard IPv4 address,
   like ::10.9.8.1. (This syntax is used only for convenience, and the
   example address is equivalent to ::a09:801.) These addresses are used
   in IPv4 tunneling mechanisms as described in section 7 on Transition
   Mechanisms.

5.5. IPv4-mapped addresses

   [RFC-2373] also delineates the notion of IPv4-mapped addresses, which
   allow the addresses of IPv4-only hosts to be represented in IPv6
   notation. The format of these addresses is 80 bits of zeros, followed
   by 16 bits of ones, followed by the 32-bit IPv4 address.





Lutchansky                                                      [Page 8]


Internet Draft      A Technical Introduction to IPv6            May 2001


   +---------+---------+--------------+
   | 80 bits | 16 bits |    32 bits   |
   |    0    |  FFFF   | IPv4 address |
   +---------+---------+--------------+

   Such addresses are written like ::ffff:192.168.0.1.  IPv4-mapped
   addresses should NEVER be used in IPv6 headers, nor entered in DNS
   records. They exist so that TCP/IP stacks which support both IPv4 and
   IPv6 can store the addresses of all hosts in an IPv6 address field,
   even hosts that only have IPv4 addresses.

   IPv4-compatible addresses are distinct from IPv6-mapped addresses.
   IPv4-compatible addresses are used to represent hosts with IPv6
   capability but are only reachable by IPv4, so an IPv6-in-IPv4
   tunneling mechanism must be used to communicate with these hosts
   using IPv6.  IPv4-mapped addresses are used internally inside a
   network device to address hosts that only have IPv4 capability, and
   thus these addresses are only useful to devices with both IPv4 and
   IPv6 connectivity. The utility of IPv4-mapped addresses will be
   discussed in section 10 about Programming and the API.

5.6. Multicast and Anycast

   The address format above describes unicast addresses -- that is,
   addresses that specify a destination of exactly one distinct network
   interface. In addition, two other types of destinations may be
   specified for IPv6 packets. Multicast, as described earlier in this
   document, is treated much the same way as IPv4. Multicast group
   addresses are assigned to organizations from the prefix ff00::/8.
   Anycast is a special mode of unicast that allows a number of nodes to
   listen to the same IP address with the expectation that a packet sent
   to that address will arrive at exactly one of the listening nodes.
   Anycast addresses are allocated by each organization from their
   unicast address allocation.

6. The Neighbor Discovery Protocol

   The mechanism used by IPv6 to automatically configure hosts new to a
   network is the Neighbor Discovery (ND) protocol, defined in
   [RFC-2461].  ND is a subset of ICMP, and provides functionality
   necessary for a host to automatically discover parameters about the
   local subnet (local network number, router addresses) and about other
   hosts on the network and how to reach them (hardware addresses of
   neighbors, duplicate address detection). It subsumes the
   functionality of the IPv4 ARP protocol and provides some of the
   functionality of address configuration protocols such as BOOTP and
   DHCP.  In fact, a network device connecting to a network for the
   first time can learn all parameters necessary to function solely



Lutchansky                                                      [Page 9]


Internet Draft      A Technical Introduction to IPv6            May 2001


   through ND information.

   Since multicasting has replaced broadcasting in IPv6, ND packets
   destined for some or all hosts on the local network are sent to a
   link-local multicast address. The address ff02::1 reaches all devices
   on a local network, and the address ff02::2 reaches all routers on
   the local network. Certain ND packets may also be destined for a
   single host, in which case they are unicast to that host's IP
   address.

   Both routers and hosts advertise their presence using router
   advertisement and neighbor advertisement messages, respectively.
   Advertisement messages are sent to all hosts periodically, or to a
   single host when requested by a router solicitation or neighbor
   solicitation message.

   Router advertisement messages contain information about the local
   network, such as local network number and maximum MTU, as well as
   information about the routes that the router is capable of reaching.

   Neighbor advertisement messages are primarily used to announce the
   hardware address of a particular host and to detect duplicate IP
   addresses.

7. Transition mechanisms

   Until IPv6 becomes natively available everywhere, sites will have to
   use transition mechanisms to allow their hosts to communicate with
   other sites that also IPv6 but are only reachable via an IPv4-only
   network.  Currently, the most common tunneling protocol is called SIT
   (for Simple IP Transition) which tunnels IPv6 inside IPv4 packets to
   allow IPv6-aware sites to communicate over the IPv4-only Internet. A
   number of different mechanisms use SIT as a transport for both
   manually-configured and automatically-configured tunnels, many of
   which are described in [RFC-2893].

7.1. The 6bone

   The initial testbed for the IPv6 protocol is called the 6bone.  Sites
   experimenting with IPv6 have set up manually-configured SIT tunnels
   to each other, creating the first world-wide IPv6 "network".  The TLA
   3ffe::/16 has been assigned to sites on the 6bone by [RFC-2471].
   Single users interested in participating in the 6bone can visit any
   one of a number of "tunnel brokers" that will automatically set up a
   static SIT tunnel.  Sites needing to connect more than one device or
   devices without direct IPv4 access should contact another 6bone site
   near them to configure a tunnel and obtain an IP allocation inside
   the 6bone TLA.  Lately, however, other transition mechanisms -- ones



Lutchansky                                                     [Page 10]


Internet Draft      A Technical Introduction to IPv6            May 2001


   that allow 6bone access (unicast-only) without having a direct 6bone
   tunnel -- have become popular.

7.2. Direct tunnelling

   Hosts with public IPv4 addresses have, of course, IPv4-compatible
   IPv6 addresses as described in section 5.4.  With minimal
   configuration, these hosts can easily communicate with other hosts
   having IPv4-compatible addresses, provided the hosts involved can
   route IPv4 packets to each other.  Communication is done using
   automatic SIT tunnels. Multicast isn't supported by this method.

7.3. 6to4

   The TLA 2002::/16 has been reserved for a protocol known as 6to4,
   specified in [RFC-3056], which is another method for creating
   automatic IPv6 tunnels over IPv4 with SIT. By embedding the IPv4
   address of a 6to4 router into the NLA and reserved fields, an entire
   /48 network can be addressed behind every public IPv4 address. Sites
   with just one static IPv4 address for their border router can assign
   IPv6 addresses to all their network devices without needing native
   IPv6 ISP service, manually-configured tunnels, or an official IPv6
   address allocation.  Routers utilizing 6to4 can route packets to 6to4
   addresses by extracting the IPv4 address of the border router from
   the destination address, then tunneling the packet using SIT to the
   6to4 router at the destination site, which will forward the packet to
   the local destination via native IPv6.

   Unfortunately, since public routing of 6to4 addresses is done by the
   IPv4 Internet, multicast isn't supported, but work is underway to
   provide such support.

7.3.1. 6to4 addressing

   This is the format for 6to4 addresses:

   +---------+----------------------------+---------+--------------+
   | 16 bits |          32 bits           | 16 bits |    64 bits   |
   |  2002   | IPv4 addr of border router | SLA ID  | Interface ID |
   +---------+----------------------------+---------+--------------+

   To find the 6to4 prefix for a particular IPv4 address, convert the
   address to hex and append it to the 2002 TLA. For example, the
   address 10.9.8.7 in hex is 0x0a090807, so the 6to4 prefix routed via
   this address is 2002:a09:807::/48. The SLA and Interface IDs can be
   allocated within a 6to4 prefix in the same manner as in any other /48
   site address block.




Lutchansky                                                     [Page 11]


Internet Draft      A Technical Introduction to IPv6            May 2001


7.3.1. Relaying 6to4 to the 6bone

   Although sites utilizing 6to4 for IPv6 connectivity can automatically
   communicate with other 6to4 sites, some method is needed for 6to4
   border routers to route to sites on the 6bone or native IPv6 links.
   Currently this is accomplished by configuring a tunnel from the
   border 6to4 router to a public 6to4 gateway router, all of which are
   listed on the 6bone website [6BONE]. [6to4ANYCAST] specifies an "IPv4
   anycast address" which would automatically be routed to the nearest
   public 6to4 gateway, allowing all 6to4 border routers to tunnel
   non-6to4 IPv6 packets to a single address, greatly simplifying 6to4
   configuration and ensuring optimal routing for tunneled IPv6 packets.
   As of this revision of this document, the specification is pending
   IANA approval.

7.4. Other transition mechanisms

   There are other tunneling methods in development that allow more
   flexibility and some support for multicast. One of these is 6-over-4
   (described in [RFC-2529]), but it requires IPv4 multicast support on
   the underlying network, which isn't available at most sites.

8. TCP and UDP

   TCP and UDP are transport protocols that work on top of the IP layer.
   Thus, when the IP layer is upgraded (say, from IPv4 to IPv6,) the TCP
   and UDP layers should need only minor changes. And indeed this is
   true; they continue to operate almost exactly the same way under IPv6
   as under IPv4, with only a few modifications to accomodate the new IP
   layer.  Services like HTTP and SMTP still operate on ports 80 and 25,
   respectively, using almost exactly the same socket API calls as they
   did before. As a result, most programs need few changes to become
   IPv6-compatible, and very little consideration needs to be applied to
   retain IPv4 compatibility as well.

   With most IPv6-compatible TCP/IP stacks, the programmer has the
   option of allowing a server to listen for connections on a port from
   both IPv4 addresses and IPv6 addresses simultaneously. Networking
   code can differentiate between incoming connections by checking
   whether the peer's address is an IPv4-mapped address or a real IPv6
   address.

   Specific changes to the BSD socket API are covered in section 10 on
   Programming and the API.

9. DNS

   Several new DNS record types have been created by [RFC-1886] for IPv6



Lutchansky                                                     [Page 12]


Internet Draft      A Technical Introduction to IPv6            May 2001


   addresses. Just as IPv4 addresses use A records for forward
   resolution (name-to-address) and PTR records for reverse resolution
   (address-to-name), IPv6 records have AAAA records for forward
   resolution and PTR records for reverse resolution. These records are
   defined by [RFC-1886]. AAAA records contain a full IPv6 address as
   the data value.  PTR records are keyed by reversing the IPv6 address,
   putting periods between every hex digit, and appending .IP6.INT.

   For example, if the IPv4/IPv6 server SERVER1.DOM.AIM with IPv6
   address 3ffe:821:9982:14::1 and IPv4 address 192.168.0.1 was the
   authoritative DNS server and mail server for the domain DOM.AIN, the
   forward and reverse lookup zone files would be similar to those shown
   below. Note that both A and AAAA records are present to support both
   hosts using IPv4 and IPv6.

   ; partial zone file for DOM.AIN
   DOM.AIN.                           NS         SERVER1.DOM.AIN.
   DOM.AIN.                           MX    10   SERVER1.DOM.AIN.
   SERVER1                            AAAA       3ffe:0821:9982:14::1
   SERVER1                            A          192.168.0.1

   ; partial zone file for 2.8.9.9.1.2.8.0.e.f.f.3.IP6.INT
   1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.0.0   PTR    SERVER1.DOM.AIN.

   [RFC-2874] defines new record types, A6 and DNAME, that support
   renumbering through indirection, but these new types are not
   implemented in many IPv6 stacks and there is some discussion about
   whether use of these records would jeopardize the stability of the
   DNS system.

10. Programming and the API

   The BSD Sockets API is the standard IP network programming API used
   on Unix and other systems. [RFC-2553] specifies extensions that are
   made to existing sockets APIs in order to accommodate the use of
   IPv6.

   New constants, PF_INET6 and AF_INET6, have been defined to identify
   the IPv6 protocol family and address family in calls to socket() and
   for use in sockaddr structs. A new form of the sockaddr struct,
   sockaddr_in6, has been defined to store address, port, and option
   information for IPv6 socket endpoints. New functionality for
   providing name and address resolution (primarily via DNS) has been
   defined also.  The gethostbyname() function has been extended to
   allow resolution of IPv6 addresses, but its use should be deprecated
   in favor of a newer, protocol-independent function getaddrinfo(),
   which is defined in the POSIX 1003.1g specification and borrowed by
   [RFC-2553].



Lutchansky                                                     [Page 13]


Internet Draft      A Technical Introduction to IPv6            May 2001


   Programs that exclusively use PF_INET6 sockets can still communicate
   with IPv4 hosts, provided that the program runs on a system that
   supports both protocols. Connections to IPv4-mapped addresses from
   IPv6 sockets will be made using IPv4, even though the sockets can be
   created and manipulated with IPv6-specific API calls.  To extend the
   compatibility to address resolution, the gethostbyname() and
   getaddrinfo() functions are capable of returning addresses of
   IPv4-only hosts as IPv4-mapped addresses, allowing programs to remain
   completely compatible with IPv4 hosts when exclusively using the new
   IPv6 API.

11. Data security and IPsec

   As in IPv4, IP-level data security is accomplished in IPv6 using
   IPsec.  Unlike in IPv4, however, IPv6 defines IPsec as a required
   feature of the IP stack.

   The goal of IPsec, as in most data security systems, is to provide
   confidentiality to prevent packets from being viewed except by the
   receiving host, and to provide authentication and integrity to
   guarentee that the data in a packet is authentic and from the correct
   sender.

11.1. AH and ESP

   [RFC-2401], which gives an overview of IPsec, divides IPsec into two
   main components: the Authentication Header (AH) defined in
   [RFC-2402], and the Encapsulating Security Payload (ESP) defined in
   [RFC-2406]. The AH is used to digitally sign packets, and the ESP is
   used to encrypt and optionally sign packets.  Although both AH and
   ESP allow any cryptographic algorithms to be used, the IPsec standard
   requires that all implementations support HMAC-MD5 for AH and DES for
   ESP.

11.2. Modes of use

   IPsec can be used in either host-to-host mode or gateway-to-gateway
   mode. Host-to-host mode is intended for use between two hosts that
   need to secure communications between themselves. Gateway-to-gateway
   mode is used by border routers to secure communications between
   specific networks. Usually this is used to create a Virtual Private
   Network (VPN) between branch offices of an organization over an
   insecure network.

   ESP has two distinct modes of operation to support host-to-host and
   gateway-to-gateway communications. Transport Mode is used between
   hosts and only encrypts the transport data and payload of each
   packet, leaving the IP headers unencrypted. Tunnel Mode is used by



Lutchansky                                                     [Page 14]


Internet Draft      A Technical Introduction to IPv6            May 2001


   gateways and encrypts the whole packet, including the IP header, then
   sends out the encrypted packet as the payload of a new packet with
   the source and destination addresses of the gateways. Tunnel mode
   reveals less information about the packet, but can only be used to
   encrypt communications between cooperative gateways. Transport mode
   only hides the payload of each packet, leaving the headers exposed,
   but can be used between arbitrary hosts without depending on the
   network topology.

11.3. IPsec on the Internet

   The eventual goal of IPsec is the wide availability of opportunistic
   encryption, in which hosts which have never communicated before are
   able to automatically obtain encryption keys for each other and use
   ESP and AH to secure the data that they exchange.  Although many
   implementations of IPsec under both IPv4 and IPv6 are available for
   many platforms, there is not yet a secure public key infrastructure
   to distribute keys across the Internet. Thus, while IPsec is used to
   create VPNs within an organization and to connect isolated hosts to a
   secure network, opportunistic encryption is still not feasible today.

12. Quality of Service in IPv6

   [To be completed]

13. Mobility support in IPv6

   [To be completed]

Author's Address

   Nathan Lutchansky
   P.O. Box 33164
   Juneau, AK  99803-3164

   Phone: (907) 780-4670
   EMail: lutchann@litech.org

References

   6BONE         The 6bone Website, http://www.6bone.net/.

   6to4ANYCAST   Huitema, C., "An anycast prefix for 6to4 relay
                 routers", Work in Progress.

   DHCPv6        Bound, J., Carney, M., Perkins, C. and R. Droms,
                 "Dynamic Host Configuration Protocol for IPv6
                 (DHCPv6)", Work in Progress.



Lutchansky                                                     [Page 15]


Internet Draft      A Technical Introduction to IPv6            May 2001


   RFC-1886      Thomson, S. and C. Huitema, "DNS Extensions to support
                 IP version 6", RFC 1886, December 1995.

   RFC-2373      Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 2373, July 1998.

   RFC-2374      Hinden, R., O'Dell, M. and S. Deering, "An IPv6
                 Aggregatable Global Unicast Address Format", RFC 2374,
                 July 1998.

   RFC-2401      Kent, S. and R. Atkinson, "Security Architecture for
                 the Internet Protocol", RFC 2401, November 1998.

   RFC-2402      Kent, S. and R. Atkinson, "IP Authentication Header",
                 RFC 2402, November 1998.

   RFC-2406      Kent, S. and R. Atkinson, "IP Encapsulating Security
                 Protocol (ESP)", RFC 2406, November 1998.

   RFC-2461      Narten, T., Nordmark, E. and W. Simpson, "Neighbor
                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
                 1998.

   RFC-2471      Hinden, R., Fink, R. and J. Postel, "IPv6 Testing
                 Address Allocation", RFC 2471, December 1998.

   RFC-2529      Carpenter, B. and C. Jung, "Transmission of IPv6 over
                 IPv4 Domains without Explicit Tunnels", RFC 2529, March
                 1999.

   RFC-2553      Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
                 "Basic Socket Interface Extensions for IPv6", RFC 2553,
                 March 1999.

   RFC-2732      Hinden, R., Carpenter B. and L. Masinter, "Format for
                 Literal IPv6 Addresses in URL's", RFC 2732, December
                 1999.

   RFC-2874      Crawford, M. and C. Huitema, "DNS Extensions to Support
                 IPv6 Address Aggregation and Renumbering", RFC 2874,
                 July 2000.

   RFC-2893      Gilligan, R. and E. Nordmark, "Transition Mechanisms
                 for IPv6 Hosts and Routers", RFC 2893, August 2000.

   RFC-3041      Narten, T. and R. Draves, "Privacy Extensions for
                 Stateless Address Autoconfiguration in IPv6", RFC 3041,
                 January 2001.



Lutchansky                                                     [Page 16]


Internet Draft      A Technical Introduction to IPv6            May 2001


   RFC-3056      Carpenter, B. and K. Moore, "Connection of IPv6 Domains
                 via IPv4 Clouds", RFC 3056, February 2001.

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





















Lutchansky                                                     [Page 17]