[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
NGTRANS WG G. Tsirtsis
Flarion Technologies
Internet Draft
Title:draft-ietf-ngtrans-6to4-DSTM-00.txt
Expires : June 2001 January 2001
Dual Stack deployment using DSTM and 6to4
<draft-ietf-ngtrans-6to4-dstm-00.txt>
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.
Abstract
It is desirable that most of IPv6 deployment is based on Dual Stack
IPv4 and IPv6 nodes so that interoperability with the current IPv4
based Internet be seamless. The 6to4 transition mechanism offers a
automated mechanisms for addressing an IPv6 site as well as
interconnectivity with other IPv6 sites when no native IPv6
connectivity is available.[DSTM] provides a mechanism for dynamic
IPv4 address allocation to Dual Stack nodes and a mechanism to send
packets over a network that only supports IPv6 routing. By combining
the two mechanisms we show how Dual Stack Intranets may be deployed
with minimum need for IPv4 address space and no native IPv6
connectivity.
INDEX
1. Introduction
2. Combining DSTM with 6to4
3. Changes to DSTM and 6to4
4. Conclusion
5. Changes from v00 to v01
Tsirtsis 1
Internet Draft Combining 6to4 and DSTM January 2001
1. Introduction
It is desirable that most of IPv6 deployment is based on Dual Stack
IPv4 and IPv6 nodes so that interoperability with the current IPv4
based Internet be seamless. The [6to4] transition mechanism offers a
automated mechanisms for addressing an IPv6 site as well as
interconnectivity with other IPv6 sites when no native IPv6
connectivity is available. DSTM provides a mechanism for dynamic
IPv4 address allocation to Dual Stack nodes and a mechanism to send
packets over a network that only supports IPv6 routing. By combining
the two mechanisms we show how Dual Stack Intranets may be deployed
with minimum need for IPv4 address space and no native IPv6
connectivity.
No new protocol is defined in this document.
2. Combining DSTM with 6to4
DSTM defines that if IPv4 routing is not supported in the DSTM
domain, IPv4 is tunnelled over IPv6 from the Dual Stack Node to the
TEP which de-capsulates and forwards over IPv4 to external network.
A small configuration problem is that TEP's address needs to be
known in advance and DSTM extends DHCPv6 to provide this
information.
Imagine a domain that
- has Dual Stack nodes.
- only supports IPv6 Routing.
- IPv6 addresses are allocated by 6to4.
- IPv4 addresses are allocated by DSTM.
In the example below, the following notation, borrowed from [DSTM]
will be used:
X will designate an IPv6 host with a dual stack, X6 will be the
IPv6 address of this host and X4 the IPv4 address
Y will designate a 6to4 border router at the boundary between
an IPv6 DSTM/6to4 domain and an IPv4-only domain.
Z will designate an IPv4-only host and Z4 its 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 host
Tsirtsis 2
Internet Draft Combining 6to4 and DSTM January 2001
DHCPv6
DNS 6to4
X6 Y6/Y4 Z4
| | |
|. . . . . . . .> Z | - X6 asks the DNS for an AAAA for "Z"
|<. . . . . . . error | - the DNS answers with an error
|. . . . . . . .> Z | - X6 asks for the A RR for "Z"
|<. . . . . . . . Z4 | - the answer is Z4
| | |
| | | - The application sends its first IPv4
| | | packet which arrives to the DTI interface
| | | (If the application is compiled for IPv6
| | | this can be done through an IPv4-mapped
| | | address).
| | |
| | | - X6 needs an IPv4 address (first use)
|====> | | - X6 queries the DHCPv6 server for an
| | | IPv4 address using DHCPv6
|<==== | | - The DHCPv6 server locates the client
| | | and provides a temporary IPv4
| | | global address.
|+++++++++>| | - The MN sends the IPv6 packet to the
| | | 6to4 router 2002:6to4::
| |--------->| - Y sends the packet to the destination Z4
| | | - Y caches the association between
| | | the IPv4 and IPv6 address of X.
When an IPv6 node wants to talk to an IPv4 only node (e.g.:
132.100.1.1) the following will happen according to DSTM:
A DNS request for AAAA/A6 will return an error. This will trigger an
A request, which will return the IPv4 address of the destination
(say 132.100.1.1). The IPv6 node will use DHCPv6 to get a temporary
IPv4 address (say 70.60.50.1). Now unlike DSTM, the packet can be
immediately tunnelled to the 6to4 router of the site:
Inner Source Address = 70.60.50.1
Inner Destination Address = 132.100.1.1
Outer Source Address = 2002:6to4::EUI1
Outer Destination Address = 2002:132.100.1.1::
The key is that a packet with Destination (2002:132.100.1.1::) in
the 6to4 domain will naturally go straight to the 6to4 gateway of
the domain.
Now the 6to4 boarder router can recognize that the above destination
address is not the normal "6to4 IPv6 address", which would require
the low 64 bits to be populated. In this case instead of
*en*capsulation the gateway needs to *de*capsulate and send the
internal IPv4 packet to the IPv4 destination.
Tsirtsis 3
Internet Draft Combining 6to4 and DSTM January 2001
The 6to4 gateway will send the IPv4 packet:
Source Address = 70.60.50.1
Destination Address = 132.100.1.1
The gateway also needs to keep the mapping between 70.60.50.1 and
2002:6to4::EUI1 (as DSTM does in TEP) so the returned packet can be
encapsulated and sent back to the Dual Stack Node.
On the returning path the 6to4 gateway will receive the following
IPv4 packet:
Source Address = 132.100.1.1
Destination Address = 70.60.50.1
The 6to4 gateway recognises the IPv4 destination of 70.60.50.1 as
the IPv6 destination 2002:6to4::EUI1 and sends it to it:
Inner Source Address = 132.100.1.1
Inner Destination Address = 70.60.50.1
Outer Source Address = 2002:132.100.1.1::
Outer Destination Address = 2002:6to4::EUI1
3. Changes to DSTM and 6to4
For the above mechanisms to work, the following needs to happen:
- DSTM nodes with 6to4 addresses SHOULD encapsulate IPv4 packets
into IPv6 packets using a destination address of the form of
2002:Z4:: where Z4 is the IPv4 address of the IPv4 only destination
- 6to4 gateways SHOULD recognise a packet with destination address
of the form 2002:Z4:: (Interface ID = 0) as a packet containing an
IPv4 packet and thus SHOULD de-capsulate and forward the packets to
its IPv4 destination. The same realisation can come from the Next
Header field of the IPv6 outer header.
4. Conclusion
We showed that combining DSTM with 6to4 one can provide a complete
solution to an Intranet that would like to utilize the Dual Stack
approach to migration but only has a few IPv4 addresses and no
native connectivity to IPv6. The combination also provides a small
improvement to the way the two transition mechanisms operate.
What do you gain:
- Combine TEP/6to4 gateway functions/boxes
- Dual Stack nodes do no need to know the address of the TEP and
thus no need to configure DHCP with it and no need to re-configure
it in a renumbering event.
Tsirtsis 4
Internet Draft Combining 6to4 and DSTM January 2001
5. Changes
6. References
[DSTM], Jim Bound et.al, Dual Stack Transition Mechanism (DSTM),
<draft-ietf-ngtrans-dstm-03.txt>, October 2000, Work in Progress.
[6to4], B. Carpenter, K. Moore, Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels, <draft-ietf-ngtrans-6to4-07.txt>,
September 2000, Work in Progress
Author's Address
George Tsirtsis
Flarion Technologies
(+44) 020 88260073
G.Tsirtsis@Flarion.com
gtsirt@hotmail.com
Copyright Notice
Placeholder for ISOC copyright.
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/