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

Versions: 00

INTERNET-DRAFT                                                 Jim Bound
NGTRANS Working Group                                     Nokia Networks
                                                         Laurent Toutain
Expires July 2001                                         Francis Dupont
                                                           ENST Bretagne
                                                            Alain Durand
                                                        Sun Microsystems

           Dual Stack Transition Mechanism (DSTM) Extensions


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.


   The Dual Stack Transition Method (DSTM) is an IPv6 transition
   mechanism that provides for the assignment of IPv4 Global Addresses
   using DHCPv6, and a Dynamic Tunneling Interface (DTI) so IPv6 nodes
   within a predominant IPv6 network can communicate with IPv4 ONLY
   nodes.  This document is an extension to DSTM to provide the ability

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 1]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

   for an IPv4 ONLY node to initiate communications with an IPv6/IPv4
   node, which has only an IPv6 address.

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 2]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

Table of Contents:

1. Introduction.................................................4
2. Terminology..................................................4
2.1 IPv6 DSTM Terminology.......................................4
2.2 Specification Language......................................5
3.  DSTMEXT1 AIIH Server Architecture View......................7
4. DSTM Deployment Example......................................8
4.1 IPv4 node to an IPv6 node...................................9
5. AIIH Server Design Model....................................10
5.1 AIIH DHCPv6/DNS Server.....................................10
5.1.1 AIIH DNS Query and DHCPv6 Processing.....................11
5.1.2. Cleaning up the AIIH IPv4 Assigned Address..............11
5.2 Links with other DNS.......................................12
6. Applicability Statement.....................................13
7. Security Considerations.....................................13
Authors' Address...............................................15

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 3]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

1. Introduction

The Dual Stack Transition Method (DSTM) is an IPv6 transition mechanism
that provides for the assignment of IPv4 Global Addresses using DHCPv6,
and a Dynamic Tunneling Interface (DTI) so IPv6 nodes within a
predominant IPv6 network can communicate with IPv4 ONLY nodes.  This
document is an extension to DSTM to provide the ability for an IPv4 ONLY
node to initiate communications with an IPv6/IPv4 node, which has only
an IPv6 address.

All of the mechanisms in DSTM [20] are applicable to this DSTM
Extension-1 (DSTMEXT1).  Added are the mechanisms for an IPv4 ONLY node
to communicate with an IPv6/IPv4 node, because the IPv6/IPv4 node is
assigned a temporary IPv4 Global Address to communicate with the IPv4
ONLY node.

DSTMEXT1 is composed of a DHCPv6 [4] server coupled with a DNS [1,2]
server (called AIIH server, for Assignment of IPv4 Global Addresses to
IPv6 Hosts). This server will allocate temporary IPv4 addresses to IPv6
hosts using DHCPv6.  This server will also be used to maintain the
mapping between the allocated IPv4 address and the permanent IPv6
address of the host. Every IPv6 host will have an IPv4 interface called
DTI (Dynamic Tunneling Interface) designed to encapsulate IPv4 packets
into IPv6 packets and resolve the address space mechanics, between IPv4
and IPv6.

2. Terminology

2.1 IPv6 DSTM Terminology

   DSTM Domain             The network areas on an Intranet where a
                           DHCPv6 Server has access to IPv6 nodes participating
                           in DSTM for that network, and IPv4 routing access
                           is not necessary within a DSTM domain.

   DSTM Border Router      A border router within a DSTM domain and
                           access to an external IPv4-ONLY domain.

   DSTM Host               A Host that supports a dual IP layer IPv4
                           and IPv6 stack, DTI, and a DHCPv6 Client

   IPv6 Protocol Terms:    See [3]

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 4]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

   IPv6 Transition Terms:  See [14]

   DHCPv6 Terms:           See [4]

   DTI:                    Dynamic Tunneling Interface. An interface
                           encapsulating IPv4 packets into IPv6 packets.

   IPv4 Global Address:    An IPv4 address that is globally routable on
                           the Internet.

   Tunnel End Point (TEP)  Destination of the IPv6 packet containing an
                           IPv4 packet.  In most cases this will be
                           a dual stack border router.

   AIIH Server             A virtual or co-located server, in an
                           implementation defined manner, that supports both
                           DHCPv6 and DNS Server functions.

2.2 Specification Language

   In this document, several words are used to signify the requirements
   of the specification, in accordance with RFC 2119 [8]. These words
   are often capitalized.

      MUST          This word, or the adjective "required", means that
                    the definition is an absolute requirement of the

      MUST NOT      This phrase means that the definition is an absolute
                    prohibition of the specification.

      SHOULD        This word, or the adjective "recommended", means
                    that there may exist valid reasons in particular
                    circumstances to ignore this item, but the full
                    implications must be understood and carefully
                    weighed before choosing a different course.
                    Unexpected results may result otherwise.

      MAY           This word, or the adjective "optional", means that
                    this item is one of an allowed set of alternatives.
                    An implementation which does not include this option
                    MUST be prepared to interoperate with another
                    implementation which does include the option.

      silently discard
                    The implementation discards the packet without
                    further processing, and without indicating an error

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 5]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

                    to the sender. The implementation SHOULD provide
                    the capability of logging the error, including the
                    contents of the discarded packet, and SHOULD record
                    the event in a statistics counter.

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 6]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

3.  DSTMEXT1 AIIH Server Architecture View

                                              |    IPv4 Internet or Intranet
        DSTM Domain Intranet                  |      IPv4 Applications
                                              |         Domain
                _____________________         |
               |                     |        |
               |   AIIH Server       |        |
               |  (DHCPv6 and DNS)   |        |
               |_____________________|        |
                            /   /           |
                             |    |           |
   __________________        |    |          _|_______
  |                  |       |    |         |        |
  | IPv6/IPv4 Node   |       |    |         |  DSTM  |
  |------------------|       |    --------->| Border |
  |  DSTM Daemon     |       |              | Router |
  |  DHCPv6 client   |<-------              |  IPv6  |
  |------------------|                      |    &   |
  |    DTI/Route     |<-------------------->|  IPv4  |
   -------------------                       ---------

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 7]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

4. DSTM Deployment Example

In the example below, the following notation will be used:

   X    will designate an IPv6 node with a dual stack
  X6    will be the IPv6 address of this node
  X4    the IPv4 address of this node
   Y    will designate a DSTM border router at the boundary between an
        IPv6 DSTM domain and an IPv4-only domain
   Z    will designate an IPv4-only node
  Z4    The IPv4-only nodes address
   ==>  means an IPv6 packet
   -->  means an IPv4 packet
   ++>  means a tunneled IPv4 packet is encapsulated in an IPv6 packet
   ..>  means a DNS query or response. The path taken by this
        packet does not matter in the examples
   "a"  means the DNS name of a node

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 8]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

4.1 IPv4 node to an IPv6 node

This example covers any scenario where an IPv4-only host wants to
establish a session with an IPv6 host, which does not have an IPv4

No modification can be made to the IPv4 host or to the application,
especially the IPv4-application cannot be recompiled.

   X4     AIIH   Y4          Z4
   X6            Y6
    |      <. . . . . . . . . |   - ask for the IPv4 address of X
    |            |            |   - this request arrives to the AIIH Server
    |            |            |
    |            |            |   - if node X does not have already a
    |            |            |     temporary IPv4 address assigned then the
    |            |            |     AIIH allocates an IPv4 address and
    |<=====      |            |     registers it in the DNS.
    |      . . . . . . . . . >|   - AIIH returns the IPv4 address to node Z4
    |            |            |
    |            |<-----------|   - Z4 sends an IPv4 packet which arrives at Y4
    |      <=====|            |   - Y4 asks the AIIH server for the IPv6 address
    |            |            |     corresponding to X4.
    |      =====>|            |   - AIIH server responds
    |<++++++++++ |            |   - The packet is tunneled to node X6
    |            |            |

Bound,Toutain,Dupont,Durand  Expires July 2001                  [Page 9]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

5. AIIH Server Design Model

The design model provides a mechanism to assign an IPv6 host an IPv4
address. An AIIH Server will assign an IPv6 host a globally routable
IPv4 address using the DHCPv6 Reconfigure-Init Message, when it is
requested to do so by the DNS server function.

5.1 AIIH DHCPv6/DNS Server

The AIIH Server supports a cooperating DHCPv6 and DNS Server and other
implementation defined software functions. The AIIH server configuration
files and database is not defined in this specification. There can be
one or many AIIH Servers on an Intranet and how they maintain
consistency and Tunnel End Point configurations for IPv6 links is
implementation defined.

The AIIH Server is an implementation where DNS, DHCPv6, and
communications between those two applications exists. These applications
MAY be co-located on the same host, but that is not a requirement of
this specification. How DNS and DHCPv6 communicate is implementation
defined . The AIIH Server SHOULD support the following operations:

     1.  Act as the Authoritative DNS Name Server for a set of IPv6
         hosts that can be queried for IPv4 Global Addresses.

     2.  Communications between the AIIH DNS server and the AIIH DHCPv6

     3.  An AIIH DHCPv6 Server that can maintain a pool of IPv4 Global
         Addresses in an implementation defined manner.

     4.  An AIIH DHCPv6 Server that can maintain Tunnel End Points for
         IPv6 Links in an implementation defined manner.

     5.  An AIIH DHCPv6 Server to process DNS AIIH IPv6 host DNS queries,
         and Reconfiguring IPv6 hosts to assign IPv4 Global Addresses to
         their interfaces.

     6.  Dynamically Updating DNS with an IPv4 Global Address for
         an IPv6 host that supports IPv4/IPv6.

An AIIH Server MUST support a dual IPv4/IPv6 network layer and
implementation of IPv4/IPv6.

An IPv4 address is assigned to an IPv4/IPv6 host, when a DNS A query is
made for a node that only has an IPv6 address (see section 5.2).  fails
to respond to a DNS A RR query.

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 10]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

5.1.1 AIIH DNS Query and DHCPv6 Processing

Once the AIIH DNS finds the IPv6 host being queried the AIIH DNS
requests from its corresponding AIIH DHCPv6 Server to assign an IPv4
Global Address to the IPv6 host being queried.

The AIIH DHCPv6 Server will look within its pool of IPv4 Global
Addresses for an address and if a Tunnel End Point address is required
for the IPv6 host to reach the router to route packets onto the
Internet. If an address is available the DHCPv6 Server will send a
DHCPv6 Reconfigure-Init Message to the IPv6 node to temporarily assign
the node an IPv4 Global Address [20].

Once the AIIH DHCPv6 server is certain that the IPv6 host has assigned
the address to an interface, the AIIH DHCPv6 Server responds back to the
corresponding AIIH DNS Server with the IPv4 Global Address assigned to
the IPv6 host being queried, or that an address could not be assigned to
this IPv6 host.

It is important to wait for an acknowledgment from the client to be sure
that the host is up before validating an IPv4 address has been assigned.
Nevertheless, this could introduce a delay incompatible with the timer
used during a DNS query. The dialog could be modified. Just after the
DNS temporary IPv4 address assignment, the AIIH DNS returns this address
but with a small TTL. The real TTL will be used if the acknowledgment is
received, otherwise the IPv4 address is deprecated for a some period of

The AIIH DNS Server will now respond to the IPv4 DNS Query as the
Authoritative DNS Name Server with an address or host not found.

The AIIH DHCPv6 Server MAY send a dynamic update to DNS [6] to add an A
type record to the Primary DNS Server, where the query came from to the
AIIH DNS Server. The Time-To-Live (TTL) field in the update MUST NOT be
set to be greater than the valid lifetime for the IPv4-Compatible
address in the DHCPv6 Extension provided to the DHCPv6 Client. It is
highly recommended to not update the DNS with an A record for the IPv6
host, unless that IPv6 host provides a permanent IPv4 Application
service needed by IPv4 hosts.

5.1.2. Cleaning up the AIIH IPv4 Assigned Address

Once the IPv4 address expires, the DHCPv6 Server will permit the IPv4
address to be reused. But before the address can be reused the DHCPv6
Server MUST delete the IPv4 address from the Primary DNS Server, through
the Dynamic Updates to DNS mechanism, if an A record was added to the
relative Primary DNS Server.

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 11]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

If an AIIH client wants to keep the temporary IPv4 address after its
expiration time, it MUST send a DHCPv6 Request Message before the
address expires.

5.2 Links with other DNS

When the Primary DNS Server for the IPv6 node receives the IPv4 hosts
query, it will do a DNS search for that IPv6 host and find that there is
an Authoritative DNS Server for that specific DNS A record, which
represents an IPv6 host. That DNS Server will be one part of the AIIH
Server software. After the AIIH DHCPv6 Server assigns the IPv6 node a
temporary IPv4 Global Address, the AIIH DNS Server will respond to the
original IPv4 DNS query authoritatively with an IPv4 Global Address for
the IPv6 host or return host Not Found.

   For Example:

     IPv4 node "v4host.abc.com" queries for "v6host1.xyz.com"

     Query reaches Primary DNS Server for "v6host1.xyz.com".

     xyz.com.  IN SOA primary.xyz.com.  etc etc.
     xyz.com          IN  NS  primary.xyz.com
     aiih.xyz.com     IN  NS  v6trans.aiih.xyz.com
     primary.xyz.com          IN   A
     v6trans.aiih.xyz.com     IN   A
     v6host1.xyz.com        IN   CNAME   v6host1.aiih.xyz.com
     v6host2.xyz.com        IN   CNAME   v6host2.aiih.xyz.com
     v6host3.xyz.com        IN   CNAME   v6host3.aiih.xyz.com

   DNS query will end up going to the authoritative server
   v6trans.aiih.xyz.com looking for v6host1.aiih.xyz.com. This permits
   the AIIH Server to now process a request for an IPv4 Global Address
   for an IPv6 host that had no IPv6 DNS AAAA Record [18].

   If DTI is present, the reverse DNS must be linked to the pool of
   addresses managed by the AIIH Server.

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 12]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

6. Applicability Statement

This mechanism is only applicable to environments where the end-2-end
connection is secure.  More needs to go in this section.

7. Security Considerations

The DSTMEXT1 mechanism can use all the defined security specifications
for each functional part of the operation. For DNS the DNS Security
Extensions/Update can be used [9, 10], for DHCPv6 the DHCPv6
Authentication Message can be used [4], and for communications between
the IPv6 node, once it has an IPv4 address, and the remote IPv4 node,
IPsec [7] can be used as DSTMEXT1 does not break secure end-to-end
communications at any point in the mechanism.




   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
        November 1987.

   [3]  S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Architecture", RFC 2460, December 1998.

   [4]  J. Bound, M. Carney, C. Perkins, and R. Droms.  Dynamic Host
        Configuration Protocol for IPv6.  draft-ietf-dhc-dhcpv6-16.txt
        November 2000 (work in progress).

   [5]  P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
        to the Domain Name System (DNS).  RFC 2136, April 1997.

   [6]  William R. Cheswick and Steven Bellovin.  Firewalls and Internet
        Security.  Addison-Wesley, Reading, MA 1994 (ISBN:

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 13]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

   [7]  IPSEC -
        S. Kent, R. Atkinson. Security Architecture for the Internet
        Protocol.  RFC 2401, November 1998.
        S. Kent, R. Atkinson. IP Authentication Header.
        RFC 2402, November 1998.
        S. Kent, R. Atkinson.  IP Encapsulating Security Payload
        RFC 2406, November 1998.

   [8]  S. Bradner.  Key words for use in RFCs to indicate Requirement
        Levels.  RFC 2119, March 1997.

   [9]  D. Eastlake and C. Kaufman. Domain Name System Security
        Extensions.  RFC 2065, January 1997.

   [10] D. Eastlake. Secure Domain Name System Dynamic Update.
        RFC 2137, April 1997.

   [11] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition
        RFC 2185, September 1997.

   [12] A. Conta and S. Deering.  Generic Packet Tunneling in IPv6.
        RFC 2473, December 1998.

   [13] E. Nordmark. Stateless IP/ICMP Translator (SIIT)
        RFC 2765, February 2000.

   [14] R. Gilligan and E. Nordmark.  Transition Mechanisms for IPv6
        Hosts and Routers.  RFC 2893, August 2000.

   [15] R. Droms.  Dynamic Host Configuration Protocol.
        RFC 2131, March 1997.

   [16] Rekhter, Moskowitz, Karrenburg, Groot.  Address Allocation
        for Private Networks. RFC 1918.  February 1996.

   [17] M. Crawford, C. Huitema. DNS Extensions to Support IPv6 Address
        Aggregation and Renumbering.  RFC 2874, July 2000.

   [18] Thomson, Narten.  IPv6 Stateless Address Configuration.
        RFC 2462, December 1998.

   [19] Hinden, Deering.  IP Version 6 Addressing Architecture.
        RFC 2373, July 1998.

   [20] Bound, Toutain, Afifi, Dupont, and Durand.  Dual Stack
        Transition Method (DSTM), draft-ietf-ngtrans-dstm-04.txt
        February 2001.

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 14]

INTERNET-DRAFT  draft-ietf-ngtrans-dstmext1-aiih-00.txt     Feruary 2001

Authors' Address

    Jim Bound
    Nokia Networks
    5 Wayside Road
    Burlington, MA 01803
    Phone: +1 781 492 0613
    Email: Jim.Bound@nokia.com

    Laurent Toutain
    ENST Bretagne
    BP 78
    35 512 Cesson
    Phone : +33 2 99 12 70 26
    Email : Laurent.Toutain@enst-bretagne.fr

    Francis Dupont
    ENST Bretagne
    BP 78
    35 512 Cesson
    Phone : +33 2 99 12 70 36
    Email : Francis.Dupont@enst-bretagne.fr

    Alain Durand
    Sun Microsystems
    901 San Antonio Road
    UMPK 17-202
    Palo Alto, CA 94303-4900
    Tel: +1 650 786 7503
    Fax: +1 650 786 5896
    Email: Alain.Durand@sun.com

Bound,Toutain,Dupont,Durand  Expires July 2001                 [Page 15]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/