Internet Engineering Task Force J. Bi
Internet-Draft Y. Wang
Intended status: Experimental X. Cheng
Expires: July 10, 2009 Tsinghua University
Jan 6, 2009
The Univer6 Architecture for IPv6 Transition
draft-jbi-universal-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Copyright and License Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Bi, et al. Expires July 10, 2009 [Page 1]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
Abstract
IPv6 transition is becoming an important research topic recently. In
traditional architecture, transition mechanisms are closely connected
with application, protocol stack, and network equipments. This makes
the transition process very complicated, and increases the difficulty
of network management. In this document, we present a new network
architecture called Univer6. It uses IPv6 as a unified middle
layer,thus can adapt to various kinds of applications and network
equipments. Univer6 will help provide a smooth transition towards
IPv6, simplify network management process, and accelerate the
development of IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirement for the architecture . . . . . . . . . . . . . . . 4
3. The Univer6 architecture . . . . . . . . . . . . . . . . . . . 6
3.1. Description of the architecture . . . . . . . . . . . . . 6
3.2. Advantages of the architecture . . . . . . . . . . . . . . 8
4. Illustration of Univer6 . . . . . . . . . . . . . . . . . . . 10
4.1. Application Interface (AI) layer . . . . . . . . . . . . . 10
4.2. Universal IPv6 layer . . . . . . . . . . . . . . . . . . . 11
4.3. Network Interface (NI) layer . . . . . . . . . . . . . . . 12
5. The challenges . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Bi, et al. Expires July 10, 2009 [Page 2]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
1. Introduction
This memo is intended to descirbe a possible direction for IPv6
transition. With the development of IPv6 protocol, IPv6 network and
test-beds are gradually built around the world, including CERNET2 in
China, Internet2 in USA, and GeAnt2 in Europe. Meanwhile, IPv6
transition is rapidly becoming an important research topic. Several
mechanism concerning IPv6 access, IPv6 tunnel, IPv6 applications have
been raised, and many transition methods have been proposed for
different network environments.
However, in traditional network architecture, the transition methods
are usually closely connected with all the factors such as
application, protocol stack and network equipments. This close
coupling increases the complexity of IPv6 transition process, and
makes it difficult to carry out network managements. In order to
solve these problems, we propose a new network architecture called
Univer6 in this document. It uses IPv6 as a unified layer between
different kinds of network infrastructures and the applications in
the upper layer, which saves existing investments in network
infrastructures, and provides a smooth IPv6 transition once and for
all from the end users' point of view. This architecture can also
make it easier for network management, and accelerate the transition
process towards IPv6.
Bi, et al. Expires July 10, 2009 [Page 3]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
2. Requirement for the architecture
With the deployment of IPv6, there will be two seperated large
networks:
o Native IPv4 network. It is the legacy of the current Internet.
The routers can only forward IPv4 packets, while the hosts may be
dual-stack by updating the software.
o Native IPv6 network. There may be no IPv4 address block available
when setting up new network. The routers can only forward IPv6
packets. The hosts are using dual-stack, or only supporting IPv6.
Even if the routers are dual-stack, there is no global IPv4
address allocated for the network.
There are also some dual-stack networks. Both routers and hosts have
dual-stack support, and both global IPv6 and IPv4 address are
allocated for the network. Such network can be viewed as the
overlapped part of native IPv4 network and native IPv6 network as
shown in Figure 1.
,----------.
,' IPv4 `
/ Native \
/ Network \
; :
| ,----------. |
: ,' ` ;
\/ Dual-Stack \/
/\ Network /\
; `. ,' :
| '--------- |
: ;
\ IPv6 /
\ Native /
`. Network ,'
'---------
Figure 1. Native IPv4, Native IPv6 and Dual-Stack Network
In the coexisting of both IPv4 and IPv6 native networks, to promote
the deployment of IPv6, some important requirements should be
addressed:
1. Protect the legacy investnment on IPv4 native network. The
routers and switches that can only support IPv4 will not be taken
place by IPv6-enabled network devices, due to high cost of new
devices and the estimation of no extra income from IPv6 in the
Bi, et al. Expires July 10, 2009 [Page 4]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
near future. End users should have the ability to access IPv6
even with no changes to the IPv4 routers and switches.
2. Provide a way for universal access. IPv4 and IPv6 are two
different "language" that can not directly talk to each other.
There has been a large amount of users in the IPv4 native
network. With the using up of IPv4 address, it is expected that
there will also be a large amount of users in the IPv6 native
network. The users in "IPv4 continent" and in "IPv6 continent"
should have the ability to access each other in an end-to-end
way.
3. Provide support for legacy IPv4 applications. Even some IPv4
applications can be modified to support IPv6, some will never be
modified to have IPv6 support. There should have support for
such IPv4 application to run over IPv6 only network.
Bi, et al. Expires July 10, 2009 [Page 5]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
3. The Univer6 architecture
3.1. Description of the architecture
Here we describe an architecture to meet the requirements analyzed
above. The Univer6 architecture is composed of three-layers. In the
"Infrastructure Layer", there may be IPv4 native network or IPv6
native network. Over the Infrastructure Layer, "Protocol Layer" can
provide univeral access to IPv6 for all the users either in the IPv4
native network or in the IPv6 native network. The Protocol Layer
should support both IPv4 application and IPv6 application in the
Application Layer over the IPv6 protocol. There is a "IPv4 Adaption"
function in the "Protocol Layer" to support IPv4 appliation running
over IPv6.
The basic idea of Univer6 is to use IPv6 as a unified middle layer
between applications and network infrastructures. As for
applications we have IPv4-only and IPv4/IPv6 applications nowadays.
And in the future, IPv6-only applications may start to come up. When
it comes to infrastructures, the situation is even more complex. We
have IPv4 native network, IPv4/IPv6 dual stack network, and IPv6
native network. And a variety of mechanisms including Tunnel Broker,
6to4, DSTM, ISATAP and Teredo have been deployed to provide IPv6
access in different networks and during different IPv6 transition
stages. Considering these factors, we paid special attention to the
adaptability of Univer6, and the proposed architecture is as shown in
Figure 2.
Bi, et al. Expires July 10, 2009 [Page 6]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
+------------+ +------------+ +------------+
| IPv4 App | |IPv4 /v6 App| | IPv6 App |
+------------+ +------------+ +------------+
+----------------------------------------+
| +----------------+ +----------------+ |
| | API Adaptation | | DNS Adaptation | |
| +----------------+ +----------------+ | Application
| +------------------------------------+ | interface layer
| | IPv6 encapsulation/decapsulation | |
| +------------------------------------+ |
+----------------------------------------+
+----------------------------------------+
| +----------+ +----------+ +----------+ |
| | Address | | Security | | Address | |
| |Validation| | | |Management| | Univeral
| | Module | | Module | | Module | | IPv6 layer
| +----------+ +----------+ +----------+ |
+----------------------------------------+
+----------------------------------------+
| +----------------+ +----------------+ |
| | API Adaptation | | DNS Adaptation | |
| +----------------+ +----------------+ | Network
| +------------------------------------+ | interface layer
| | IPv6 encapsulation/decapsulation | |
| +------------------------------------+ |
+----------------------------------------+
+------------+ +------------+ +------------+
| IPv4 Native| | Dual stack | |IPv6 Native |
+------------+ +------------+ +------------+
Figure 2. Univer6 architecture
From Figure 2, we can see that Univer6 consists of three layers:
o Application interface (AI) layer. This layer provides support for
the applications in the upper layer, and handles all data packets
sent from/to them. In order to support applications, this layer
can provide a group of new API, or carry out translation between
IPv4 and IPv6 API's. Meanwhile, since IPv4 applications need 32-
bit IPv4 addresses to work, AI layer should provide addresses in
the correct format. Also, in order to use IPv6 as a unified
middle layer, all packets from user applications should be
processed first (encapsulated if necessary) into IPv6 packets.
This task is carried out in AI layer too.
Bi, et al. Expires July 10, 2009 [Page 7]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
o Universal IPv6 layer. This is a unified middle layer in Univer6
architecture, and tasks are mainly concerned about IPv6 protocol
itself. In this layer, we designed a security module to provide
protections. Mechanisms like IPv6 firewall deal with not only
IPv6 security issues, but also security problems during IPv6
transition. We have also designed an address validation module to
ensure the validity of IPv6 addresses. This will make IPv6
address a trustable identifier, and help with network management.
o Network interface (NI) layer. This layer performs actual data
packet transfer. So its main task is to find a proper way to
deliver packets according to different network environments. Most
of existing transition mechanisms can be included into this layer
and applied. Since IPv6 is used as a unified middle layer,
encapsulation and decapsulation may be needed in this layer in an
IPv4 network environment. In IPv6 environment, packets can be
directly delivered, and NI will carry out the task of IPv6 network
access.
3.2. Advantages of the architecture
Compared with the traditional network architecture, Univer6 have some
advantages in the following areas:
1. Smooth IPv6 transition. In the traditional architecture,
transition mechanisms are closely related to infrastructures and
applications. If the network equipments get upgraded or changed,
users have to make corresponding adjustments. This causes much
trouble for users during different stages of IPv6 transition.
Univer6 will help solve this problem. From the user's point of
view, when Univer6 is deployed, it will feel like the transition
to IPv6 is finished once and for all, while equipments in the
network can be gradually updated or replaced from IPv4 to dual
stack, and finally to IPv6. For ISPs and network administrators,
this means existing investments can be saved, and they can
provide their customers with IPv6 service immediately.
2. Network management. In the traditional architecture, if a host
is located in a dual stack network environment, it will have two
different kinds of identifiers (IP addresses) at the same time.
This will make it harder to build up an identifying system, and
bring extra complexity to network configuration and management.
In Univer6, IPv6 is used as a universal middle layer for all
hosts. The vast space of IPv6 address can provide a global
identification for all the users. Furthermore, after we deploy
address validation mechanism in Univer6, each user can be
correctly identified by its address. This will simplify the
network management process, and make network configuration much
Bi, et al. Expires July 10, 2009 [Page 8]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
easier and faster.
3. IPv6 usage. Currently, most network applications use IPv4
protocol. Although many are being upgraded to support IPv6, the
number of IPv6 applications is still quite small. This results
in the fact that many IPv6 networks are not put into use often
enough, and valuable bandwidth resources are being wasted. In
Univer6 architecture, we can provide support for IPv4
applications in the upper layer, and transfer data packets by
using IPv6 networks in the lower layer. This will bring IPv4
applications into IPv6 networks, and make full use of existing
IPv6 bandwidth.
Bi, et al. Expires July 10, 2009 [Page 9]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
4. Illustration of Univer6
4.1. Application Interface (AI) layer
The function of AI layer is to provide support for the network
applications in the upper layer, and carry out IPv6 encapsulation /
decapsulation process if necessary. The modules in this layer are
shown in Figure 3.
+------------------------------------------------+
| +------------+ +------------+ +------------+ |
| | IPv4 App | |IPv4 /v6 App| | IPv6 App | |
| +------------+ +------------+ +------------+ |
+------------------------------------------------+
| |
| API call | DNS resolution
\/ \/
+------------------------------------------------+
| +----------------+ +----------------+ |
| | API Module | | DNS Module | |
| +----------------+ +----------------+ |
+------------------------------------------------+
| | | |
| | | Packets |
| | \/ |
| | +---------------------------+ |
| | | Packet Management | |
| | +---------------------------+ |
| | Address | | |
| | Request | IPv4 | |
| | \/ | |
| | +----------------+ | IPv6 |
| | |IPv6 Encap/Decap| | |
| | +----------------+ | |
| | | | |
| \/ \/ \/ |
+------------------------------------------------+
Figure 3. Application Interface (AI) layer
The function of API module is to provide programming interface
support for upper layer applications. It contains a group of IPv4/
IPv6 adaptive interfaces, and carries out automatic translation /
conversion between IPv4 and IPv6 API's when it's necessary. For the
design of programming interface, IETF v6ops workgroup has proposed
some basic guidelines for IPv4/IPv6 application development . As for
API translation, existing mechanisms like BIA [RFC3338] contains some
similar function modules, and can be used as a reference during
Bi, et al. Expires July 10, 2009 [Page 10]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
standardization process.
DNS module handles address resolution requests from applications, and
its task is to provide addresses in the correct formats. Since IPv6
is the unified middle layer in Univer6, IPv6 addresses will be
acquired without difficulty. However, if the upper layer application
uses IPv4, DNS module should reply with a 32-bit IPv4 address. If
the host is located in an IPv4 or dual stack environment, this
address can be acquired directly from the network. If the network
environment is IPv6, we can use a mechanism to generate an IPv4
address (like BIS) for the application. Currently, transition
mechanisms like BIA and BIS contain some similar functions, and we
are also carrying out research to support IPv4 applications in IPv6
environment. The results from these researches can be used for
making standards for the DNS module.
In the data packet plane, all packets from AI layer are finally
delivered to the universal IPv6 layer. IPv6 packets can be delivered
directly, and IPv4 packets will be encapsulated in an IPv6 header.
Meanwhile, packets from IPv6 layer will be de-encapsulated (if
necessary) and passed on to the user applications.
4.2. Universal IPv6 layer
After going through AI layer, all packets delivered to this layer are
in the format of IPv6. So, Universal IPv6 layer only has to deal
with specific issues concern IPv6 protocol. No encapsulation/de-
encapsulation process is needed, and packets can be sent to NI layer
without modification. In this layer, modules are inserted to provide
different IPv6 features including security, mobility, configuration,
etc. Meanwhile, in order to provide necessary communication for the
other two layers, an address management module is introduced into
this layer. Requests from DNS are handled in this module, and
addresses acquired from the lower layer are kept in this module, too.
The most important modules in this layer are:
o Address Validation Module. In IPv6 protocol, the 128 bit address
space can give every user in the world a global IPv6 address.
This address can be used as an identifier for the user, and become
a helpful factor for network configuration and management.
However, in current network, the problem of IP address spoofing is
very serious. If we want to set up an identification system using
IPv6 address, we should first solve the issue of IPv6 address
validation. Currently, a lot of researches on address validation
are being carried out, and some mechanisms like SAVA
[draft-baker-sava-simple-00] and deployment guidelines
[draft-wu-sava-testbed-experience-06] have been proposed. These
Bi, et al. Expires July 10, 2009 [Page 11]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
research results can be integrated into the address validation
module in Univer6.
o Security Module. This module deals with not only security issues
of IPv6 protocol itself, but also security issues during different
stages of IPv6 transition, like security issues for each
transition mechanism, risks brought up by IPv4/IPv6 co-existence,
effects on existing IPv4 security architecture by applying IPv6,
etc. Particularly, the effect brought by IPv6 address allocation
needs to be carefully considered. In most IPv4 firewalls and
other security mechanisms, IP address always plays a very
important role. Rules and ACL's (Access Control List) often
contain one or many fixed IP addresses. However, IPv6 uses some
new features like SLAAC to acquire an address, and this acquired
address may even change from time to time. This causes great
challenge to traditional security mechanisms, and may affect their
performance and effectiveness. Therefore, the research for a new
IPv6 firewall architecture is quite necessary. Currently, the
v6ops workgroup at IETF have proposed some drafts about IPv6
transition security [RFC4942], and researches on a proper and
comprehensive solution mechanism are being carried out.
o Address Management Module. This module provides a communication
path between Application Interface layer and Network Interface
layer. When a host is connected to a network, addresses acquired
from the network will be passed to this module from the NI layer.
When DNS module in the AI layer sends a DNS request, this module
will return the correct address according to the requirements.
For some transition mechanisms like DSTM, hosts should ask a
server for an IP address. This address application process is
actually carried out in the NI layer, but the triggering of such a
process is handled by this module.
Aside from these modules, we can also insert many other modules that
correspond to some IPv6 features. Like mobility, configuration,
multi-homing, etc. With the development of IPv6 protocol, new
modules can be continuously added into this layer, and provide better
services for the users.
4.3. Network Interface (NI) layer
Network interface (NI) layer performs actual data packet transfer.
So its main task is to find a proper way to deliver packets according
to different network environments. The modules in this layer are
shown in Figure 4.
Bi, et al. Expires July 10, 2009 [Page 12]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
+-----------------------------------------------------------+
| +--------+ +--------+ +---------------------------------+ |
| | | | | |Access/Transfer Method Management| |
| | | | | +---------------------------------+ |
| | IP | | Network| |
| |Address | |Environ-| |
| |Acquire/| | ment | +--------+ +--------+ +--------+ |
| | Apply | | Detect | | Tunnel | | Overlay| | Direct | |
| | | | | | Access/| | Access/| | Access/| |
| | | | | |Transfer| |Transfer| |Transfer| |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
+-------------/---|---\-------------------------------------+
/ | \
/ | \
+-------+ +-------+ +-------+
| IPv4 | | Dua | | IPv6 |
| Native| | stack | | Native|
|Network| |Network| |Network|
+-------+ +-------+ +-------+
Figure 4. Network Interface (NI) layer
Network environment detection module detects the host's network
environment. During different stages of transition, transition
mechanisms may change from time to time. Network equipments may be
upgraded or changed, and some functions may be turned on / off.
Meanwhile, a mobile host like notepad may be located in different
kinds of networks at different time. All these situations call for
an environment detect module. This module will gather information
from the lower layers, including IP protocol in use, IP address, and
transition strategy. This information is then provided to other
modules to make proper decisions. Generally speaking, when a user is
connected to a network, the network environment will not change very
frequently (for mobile users in wireless LAN, the situation may be a
little different). So, the network environment detection module only
has to detect once at the beginning of network access, and
periodically check the environment change at a lower frequency after
that.
Access / transfer management module is the most important module in
this layer. It will choose proper strategies to carry out IPv6
access and data packet transfer. Basically, there are three kinds of
IPv6 access and data transfer: direct access / transfer, tunnel
access / transfer, and overlay access / transfer. When a host is
located in an IPv6 native network, or a dual stack network that
connects to IPv6 backbone network, the direct access mechanism can be
used, and data packets are sent in the form of IPv6. If the host is
in an IPv4 network, some mechanisms like configured tunnel or 6to4
Bi, et al. Expires July 10, 2009 [Page 13]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
[RFC3056] will be needed to gain access to IPv6 network. IPv6-in-
IPv4 tunnel is the most common mechanism today, and data packets are
sent through such tunnels in the form of IPv6-in-IPv4 packets. In
the early stage of transition, groups of medium-sized IPv6 enterprise
/ ISP networks will be located around the world. The separated
networks seem like a group of IPv6 islands distributed in the
Internet, so an overlay mechanism can be introduced to connect them
with each other, and to the IPv6 backbone network. In a nutshell,
most existing transition mechanisms can be integrated into this
module and used for suitable scenarios. As for the automatic network
environment detection mechanism, the v6ops workgroup in IETF has
proposed some guidelines and possible solutions
[draft-palet-v6ops-auto-trans-02]. These guidelines and solutions
can be used to help make final standards of the access / transfer
module.
IP address acquire / apply module is another useful module in the
network interface layer. On one hand, when a host gets connected to
a network, this module will collect the address information of the
host, and provide both IPv6 and IPv4 addresses (if any) to the
management module in the upper layer. On the other hand, if the host
is located in an IPv6 native network and needs to communicate with
another host using IPv4, mechanisms like DSTM will be needed to apply
for a temporary IPv4 address from the server. IP address acquire /
apply module will send out such requests to the server, and deal with
possible authentication / responses from the server. Also, if two
hosts are both located in IPv6 native networks, but the applications
on them use IPv4 protocol, it is necessary for both of them to find a
way to assign an IPv4 address for each other. We have designed a
protocol to carry out IPv4 address negotiation between two IPv6
hosts, and this protocol will also be integrated into the IP address
acquire / apply module.
Bi, et al. Expires July 10, 2009 [Page 14]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
5. The challenges
We have described Univer6 and its modules in detail. In order to
improve the features of Univer6 and put it into real use, there are
still some issues to be considered in the future:
o Module Standardization. Currently, many transition mechanisms
have been proposed, and some of them are being deployed and used
in different networks. During the design of Univer6, it will be
very helpful to consider these existing mechanisms, and try to
make Univer6 compliant with them. Research on other mechanisms
will also provide some useful tips for designing a better
architecture, and make the final standards of Univer6 more
comprehensive.
o Security. As mentioned in the previous sections, the security
issues exist not only in IPv6 itself, but also in IPv6 transition.
Security research on IPv6 like firewall is still at an early
stage, as it goes on, many new features will start to come up.
Also, existing IPv4 mechanisms should be taken into consideration.
So, it is an important issue to design a flexible security module
for Univer6.
o Application Mode. Nowadays, most IPv6 applications come from
simply upgraded IPv4 applications. If the new features of IPv6
protocol can be fully researched and brought into use, it will
greatly accelerate IPv6 transition. Univer6 uses IPv6 as a
unified middle layer, and we will try to provide new application
modes based on it. For example, after we deploy address
validation mechanism in the network, each host can be identified
by its own IPv6 address, and source address information in the IP
header can be used to provide different kinds of services. We are
planning to design a mechanism to provide different levels of QoS
(Quality of Service) for different types of IPv6 addresses. We
can use 4 to 8 bits in the IPv6 address as a sign for different
user levels and kinds of application types. Network
administrators and ISP's can make necessary adjustments on the
routers to optimize the transfer process according to different
flow types. This will provide a better user experience, as well
as improve the network management process.
Bi, et al. Expires July 10, 2009 [Page 15]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
6. IANA Considerations
This document makes no request of IANA.
Bi, et al. Expires July 10, 2009 [Page 16]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
7. Security Considerations
TBD
Bi, et al. Expires July 10, 2009 [Page 17]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
8. References
8.1. Normative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
RFC 3338, October 2002.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942,
September 2007.
8.2. Informative References
[draft-baker-sava-simple-00]
Baker, F., "Simple Source Address Validation", Mar 2007.
[draft-palet-v6ops-auto-trans-02]
Palet, J., Diaz, M., and M. Mackay, "Evaluation of IPv6
Auto-Transition Algorithm", Oct 2004.
[draft-wu-sava-testbed-experience-06]
Wu, J. and J. Bi, "SAVA Test-bed and Experiences to Date",
May 2008.
Bi, et al. Expires July 10, 2009 [Page 18]
Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009
Authors' Addresses
Jun Bi
Tsinghua University
FIT 3-212
Beijing 100084
P.R.C
Phone: +86-10-62795818-6270
Email: junbi@tsinghua.edu.cn
You Wang
Tsinghua University
FIT 4-204
Beijing 100084
P.R.C
Email: wangyou@netarchlab.tsinghua.edu.cn
Xiangbin Cheng
Tsinghua University
FIT 4-204
Beijing 100084
P.R.C
Email: cxb@netarchlab.tsinghua.edu.cn
Bi, et al. Expires July 10, 2009 [Page 19]