Network Working Group Qiong Sun
Internet Draft Chongfeng Xie
Intended status: Informational China Telecom
Expires: April 24, 2011 Xing Li
CongXiao Bao
CERNET Center/Tsinghua University
Ming Feng
China Telecom
March 6, 2011
Considerations for Stateless Translation (IVI/dIVI) in Large SP
Network
draft-sunq-v6ops-ivi-sp-02.txt
Abstract
With the approaching exhaustion of IPv4 address space, large-scale
SPs are now faced with the only real option to deploy IPv6 in a
timely manner. In order to achieve smooth transition to IPv6,
migration tools should be introduced for different deployment models.
Among different IPv6 transition mechanisms, dIVI is a prefix-specific
and stateless address mapping method which can directly translate
IPv4 packet to IPv6 packet. This document describes the challenges
and requirements for large SP to deploy IPv6 in operational network,
the experimental results of dIVI in our laboratory and the
considerations for dIVI deployment in large SP operational network.
Status of this Memo
This Internet-Draft is submitted 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
Sun Expires September 24 2011 [Page 1]
Internet-Draft Considerations for Stateless Translation March 2011
This Internet-Draft will expire on September 6,2011.
Copyright Notice
Copyright (c) 2011 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. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 3
2. Terminologies ............................................... 3
3. Problem Statement ........................................... 3
4. Laboratory experiment........................................ 5
4.1. Experiment environment.................................. 6
4.2. Experiment configuration................................ 7
4.3. Experiment results...................................... 7
5. dIVI Deployment Scenario..................................... 9
5.1. Network Architecture for Large SP Network............... 9
5.2. dIVI Deployment Scenario in Operational Network.........11
6. Considerations for dIVI deployment.......................... 12
6.1. Addressing ............................................ 12
6.2. Routing ............................................... 13
6.3. DNS ................................................... 13
6.4. AAA and User Management................................ 13
6.5. Network management..................................... 14
6.6. dIVI CPE Requirements and Configuration ................14
6.7. dIVI Xlate Placement in Large SP Network ...............14
6.8. ALG consideration ......................................15
7. Security Considerations..................................... 15
8. IANA Considerations ........................................ 15
9. References ................................................. 15
9.1. Normative References................................... 15
10. Acknowledgments ........................................... 16
Sun Expires September 6, 2011 [Page 2]
Internet-Draft Considerations for Stateless Translation March 2011
1. Introduction
The dramatic growth of the Internet is accelerating the exhaustion of
available IPv4 addressing pool. It is widely accepted that IPv6 is
the only real option on the table for the continued growth of the
Internet. However, IPv6 deployment is a huge systematic project and a
lot of challenges will arise especially in large SP operational
network.
In order to achieve smooth transition to IPv6, migration tools should
be introduced for different deployment models, among which dIVI is a
stateless translation mechanism with good scalability. This document
describes the challenges and requirements for large SPs in IPv6
transition period. Then, we introduce dIVI experimental results in
our laboratory. And finally, the considerations for designing and
deploying dIVI in operational network are discussed in terms of
addressing and routing, DNS deployment requirement, AAA support and
user management, network management, CPE requirement and Xlate
placement.
2. Terminologies
This document uses the terminologies defined in [I-D.ietf-behave-
v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-
address-format], [I-D.ietf-behave-v6v4-xlate-stateful], and [I-D.xli-
behave-ivi].
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. Problem Statement
It is well known that the pool of public IPv4 addressing is nearing
its exhaustion. The '/8' IANA blocks for Regional Internet Registries
(RIRs) are projected to 'run-out' towards the end of 2011. Credible
estimates based on past behavior suggest that the RIRs will exhaust
their remaining address space by early 2012, apart from the
development of a market in IPv4 address space. Thus, it will become
much more difficult to get available public IPv4 addresses. In the
same time, a lot of emerging applications, e.g. Apple's iPad,
Motion's BlackBerry, etc. will quickly deplete the available
addresses. This has led to a hightened awareness among the providers
to consider introducing IPv6 to keep the Internet operational.
It has been widely accepted that the end goal of IPv6 transition is
to achieve an end-to-end IPv6-only network, and IPv4 can eventually
Sun Expires September 6, 2011 [Page 3]
Internet-Draft Considerations for Stateless Translation March 2011
be turned off. However, since it will have impact on almost the
entire world, it will take a considerable period of time to reach the
ultimate goal. As a result, IPv4 and IPv6 need to coexist during the
whole transition period. In this document, we mainly focus on IPv6
migration issues from large ISP's point of view. In order to
facilitate smooth IPv6 migration, some factors need to be taken into
consideration especially for large SPs. There are ten major
requirements:
1. It should deploy in an incremental fashion and the overall
transition process should be stable and operational.
2. It should largely reduce IPv4 public address consumption.
3. It should accelerate the deployment of IPv6, rather than just
prolonging the lifecycle of IPv4 by introducing multiple layers of
NAT.
4. There should be no perceived degradation of customer experience.
As a result, IPv6 transition mechanisms should provide IPv4
service continuity.
5. It should achieve scalability, simplicity and high availability,
especially for large-scale SPs.
6. It should have user management and network management ability.
7. It should support user authentication, authorization and
accounting as an essential part of operational network.
8. Most ISPs need some kind of mechanisms to trace the origin of
traffic in their networks. This should also be available for IPv6
traffic.
9. It should have good throughput performance and massive concurrent
session support.
10.It should maintain the deployment concepts and business models
which have been proven and used with existing revenue generating
IPv4 services.
All existing IPv6 transition mechanisms can be widely divided into
three categories: dual-stack solution, translation-based solution and
tunnel-based solution. In this document, we mainly concentrate on
stateless translation mechanism: dIVI. The original stateless
IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, [I-D.ietf-
behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-
Sun Expires September 6, 2011 [Page 4]
Internet-Draft Considerations for Stateless Translation March 2011
behave-address-format],[I-D.xli-behave-ivi]. But it cannot use the
IPv4 addresses effectively. The stateless dIVI[I-D.xli-behave-divi]
is a double translation mechanism which includes a 1:N stateless
translator and a 1:1 Hgw translator. The 1:N stateless translator is
implemented in the border between the IPv6 network and the IPv4
Internet. It translates the packets between IPv4 and IPv6 with the
1:N stateless address mapping. The 1:1 Hgw translator is implemented
between an IPv6 network and user's end system. It translates the
packets between IPv4 and IPv6 with 1:1 stateless address mapping. In
addition, the home gateway translator maps random source port numbers
to restricted port number based on the extended IPv4-translatable
address format and keeps the mapping table in database for the port
number mapping of the retuning packets and all the packets in the
same session.
dIVI support bidirectional communication initiated from IPv4 and IPv6.
It can be deployed in an IPv6-only access network, in which
operational and maintenance cost can be reduced. It has very good
scalability and can largely reduce IPv4 address consumption.
In this document, we firstly demonstrate the laboratory experimental
results of dIVI in section 4. We can see that dIVI can support most
of the current IPv4 applications in IPv6-only access network, while
largely reducing IPv4 address consumption. And then dIVI deployment
model and considerations in large operational network are proposed in
section 5 and section 6 respectively. Some important factors need to
be taken into account when introducing dIVI. Since most challenges in
dIVI have no big difference compared to an IPv6-only environment, we
strongly recommend that related network elements should take the
corresponding modifications in order to guarantee the IPv6 transition
process to be operational and manageable.
4. Laboratory experiment
We have tested dIVI using the prototype in our laboratory. The major
objective listed in the following is to verify the functionality and
performance of dIVI:
O Verify how to deploy dIVI in practical network.
O Verify what applications can be used in dIVI.
O Verify what Operating Systems can be supported in dIVI.
O Verify the effect of user experience with limited ports.
O Verify the performance of dIVI.
Sun Expires September 6, 2011 [Page 5]
Internet-Draft Considerations for Stateless Translation March 2011
4.1. Experiment environment
We have tested dIVI in our laboratory. The network topology is
depicted in Figure 1.
+-----+ +-----+
|Host1+--+Hgw1 +------+ ------
+-----+ +-----+ | //// \\\\
/-+--\ +----------+ // \\
// \\ | | | |
+-----+ +-----+ | IPv6 | | IVI Xlate| | IPv4 Internet |
|Host2+--+Hgw2 +-+ Network +---| +--+ |
+-----+ +-----+ \\ // | | \\ //
|---+/ +----------+ \\\\ ////
| | ------
+-----+ +-----+ | |
|Host3+--+Hgw3 +----+ |
+-----+ +-----+ | ------
| //// \\\\\
| |/ |
+----------------------+ IPv6 Internet |
| |
|\ /
\\\\ /////
------
Figure 1 dIVI topology in the test
There are three key components in the test:
o The Hosts are dual-stack customers, who could run IPv4 application,
IPv6 application or dual stack application.
o The Home Gateways (Hgw) are dIVI translator in user side. It
translates the packets between IPv4 and IPv6 with 1:1 stateless
address mapping, and maps random source port numbers to restricted
port number.
o The Xlate translates the packets between IPv4 and IPv6 with the
1:N stateless address mapping.
The network between Hgw and Xlate is IPv6-only, and the network
behind Hgw is dual-stack. Thus, the hosts behind Hgw can communicate
with both IPv4 Internet and IPv6 Internet.
Sun Expires September 6, 2011 [Page 6]
Internet-Draft Considerations for Stateless Translation March 2011
4.2. Experiment configuration
For address configuration, each host will use two IPv6 addresses: one
is IVI6 address which is synthesized in Hgw with the IVI4 address and
port-related information, and the other is non-IVI IPv6 address which
is used for native IPv6 communication. We should notice that only
non-IVI IPv6 address needs be allocated to end users. Besides, each
user will get an IVI4 address from Hgw.
For routing configuration, both IVI address and non-IVI address need
to be imported into the IPv6-only network.
For port configuration, since there are 65536 TCP/UDP ports for each
IP address, and in fact one can use hundreds only for normal
applications, so one IPv4 address can be shared by multiple customers.
In our experiment, we selected ratio to be 128. That is to say, one
IPv4 address is shared by 128 users, and there are 512 available
ports per user.
For DNS configuration, there is no need to have additional DNS64 for
dIVI. Only an IPv6 DNS server with A/AAAA records is needed and the
DNS address is manually configured in Hgw. Besides, Hgw has
implemented DNS Proxy and it will convert an IPv4 DNS
request/response to IPv6 DNS request/response.
For ALG configuration, there is no need to deploy specific ALG for
IPv4 applications in dIVI.
4.3. Experiment results
In our laboratory, we mainly have taken the following tests:
o Application test: The applications we have tested include web,
email, Instant Message, ftp, telnet, SSH, video, Video Camera, P2P,
online game, Voip, VPN and so on.
o Operating System test: The OS we have tested includes Win7, VISTA,
windows XP.
o Performance test: We have measured the parameters of concurrent
session number, throughput performance.
Sun Expires September 6, 2011 [Page 7]
Internet-Draft Considerations for Stateless Translation March 2011
The experimental results are listed as follows:
|----------------------|-------------------------------------------|
| Type | Experiment Result |
|----------------------|-------------------------------------------|
| Application test | dIVI hosts can support web, email, im, ftp|
| | , telnet, SSH, video, Video Camera, P2P, |
| | online game, voip, and so on. |
|----------------------|-------------------------------------------|
| Operating System test| dIVI can widely support Win7, VISTA, |
| | windows XP. |
|----------------------|-------------------------------------------|
| | The performance test for dIVI Xlate is |
| | carried out on a normal PC. |
| Performance test | Due to limitation of the PC hardware, the |
| | overall throughput is not quite good. |
| | However, it can still support more than |
| | one hundred million concurrent sessions. |
|----------------------|-------------------------------------------|
Figure 2 dIVI test result
From the experiment, we can have the following conclusions:
1. dIVI can have good scalability. Xlate does not need to maintain
any session state, and only limited session states have to been
maintained in Hgw for its customer.
2. dIVI can be deployed in an incremental way. The most complicated
part of dIVI is addressing and routing. The configuration for DNS
and ALG is very simple.
3. dIVI can support a majority of current IPv4 applications.
4. dIVI can support a variety of Operating Systems.
5. With the ratio of 128 (512 maximum concurrent sessions), there is
no perceived degradation of customer experience.
However, in the current status of equipment, e.g. BRAS, end system,
etc., the support for IPv6-only function has not been fully
accomplished. Therefore, there are still some limitations which would
be improved in the next version of dIVI development when deploying
dIVI prototype in practical operational network:
Sun Expires September 6, 2011 [Page 8]
Internet-Draft Considerations for Stateless Translation March 2011
1. Address assignment process have not been integrated with existing
address allocation system.
2. Currently, IVI routing entries are configured manually.
3. Hgw has not integrated PPPoE functionality with dIVI functionality.
4. AAA system has not supported IVI-related (or IPv6-only) functions.
With regard to the listed IPv6 transition requirements in section 3,
most of them can be satisfied by dIVI, except for the requirement of
network management and user management. These two points should be
paid special attention for large SPs, which will be further discussed
in section 6.
5. dIVI Deployment Scenario
In order to investigate the ways to deploy dIVI in operational
network, we firstly briefly discuss network architecture for large SP
network. Then dIVI deployment model is introduced.
5.1. Network Architecture for Large SP Network
In large SPs, the generic network topology can be divided into four
main parts (as depicted in Figure3): the Customer Premises Network
(CPN), the Access Network (AN), the Metro Area Network (MAN), and the
Backbone Network.
----- ------
// \\ // \\ ------ ----------
/ \ / \\ // \\ // CPN
| +------+ +----+ \ / ----------
| | | Metro +BRAS| |-----|--- End System
| Backbone|Core | Area |/SR | Access | | ----------
| Network |Route | Network +----+ Network | CPE | ----------
| | | |AAA | |-----|--- End System
| +------+ +----+ / \ ----------
\ / \ / \\ // \\
\\ // \\ // ------ ----------
---- ------
Figure 3 Network Architecture for Large SP Network
Sun Expires September 6, 2011 [Page 9]
Internet-Draft Considerations for Stateless Translation March 2011
1. CPN is the part of the network by a customer when connecting to an
ISP's network which includes the CPE and the last hop link.
2. In Access Network, a very wide variety of access technologies can
be used, including ADSL, Ethernet, PON, ATM, WIFI, etc.
3. MAN is the aggregated network for customers in one single metro,
with the vast range of size. In most metro networks, BRAS is
connected to Core Router directly, while for a small portion of
large metro networks, BRAS is connected to Core Routers via
aggregated routers.
4. Backbone network is to offer transit service between MANs and
other ISPs.
There are typically two network models for fixed broadband access
service: one is to access using PPPoE/PPPoA authentication method
while the other is to use IPoE. The first one is usually applied to
Residential network and SOHO networks. Subscribers in CPNs can access
broadband network by PPP dial-up authentication. BRAS is the key
network element which takes full responsibility of IP address
assignment, user authentication, traffic aggregation, PPP session
termination, etc. Then IP traffic is forwarded to Core Routers
through Metro Area Network, and finally transited to external
Internet via Backbone network.
The second network scenario is usually applied to large enterprise
networks. Subscribers in CPNs can access broadband network by IPoE
authentication. IP address is normally assigned by DHCP server, or
static configuration.
Sun Expires September 6, 2011 [Page 10]
Internet-Draft Considerations for Stateless Translation March 2011
5.2. dIVI Deployment Scenario in Operational Network
The deployment model of dIVI in operational network is depicted in
Figure4.
---- -----
// \\ // \\ --------- --------
/ \ / \ // \\ // CPN
| +-----+ +----+ \ / --------
| | | Metro |BRAS| |-----|--End System
| Backbone|Core | Area |/SR | Access | | --------
| Network |Route| Network +----+ Network | CPE | --------
| | | |AAA | |-----|--End System
| +-----+ +----+ / | \ --------
\ / \ / \\ // | \\
\\ // \\ // -------- | ---------
---- ----|-- |
| |
-----------------| | |----------------| | |---------|
\ | / \ | / |
\---|--- / \--|--/ |
IPv6/IPv4 | dIVI | IPv6-only | Hgw | IPv6/IPv4 |
Internet | Xlate | Network |(CPE)| Network |
/ ------- \ / ----- \ |
/ \ / \ |
----------------| |----------------| |--------|
Figure 4 dIVI Deployment in Operational Network
In stateless dIVI, the network between Hgw and Xlate is an IPv6-only
network, in which the operational and maintenance cost can be greatly
reduced. The access network behind Hgw can either be IPv4-only or
dual-stack. Thus, IPv4-only system and dual-stack system can
communication with IPv4 Internet using shared IPv4 address by dIVI
and the dual-stack system can also communicate with IPv6 Internet
directly.
In operational network, Hgw can usually be integrated with CPE, while
Xlate can be in someplace of MAN or Backbone Network. Subscribers can
get IPv6 address from BRAS/SR after user authentication stage. Then,
IVI-related route should be imported into the IPv6-only network
between Xlate and Hgw. The detailed considerations for dIVI
deployment will be discussed in section 6.
Sun Expires September 6, 2011 [Page 11]
Internet-Draft Considerations for Stateless Translation March 2011
6. Considerations for dIVI deployment
This section describes the considerations for dIVI deployment in
large operational network.
The major differences between dIVI deployment in laboratory and
operational network lie in:
1. Operational network is a commercial network with strict user
management requirement, while in laboratory it is simple and
straightforward.
2. Operational network has different kinds of network equipments, e.g.
BRAS/SR, CPE, Radius, etc. It would be more difficult to take
modifications on all of these equipments.
3. Operational network has a large number of customers. Thus, it
would be impossible to take manual configuration for all customers.
In this section, we try to outline considerations for dIVI deployment
on large SP network. Some of the features are not specific to dIVI,
but rather to a general requirement on all IPv6 transition techniques.
6.1. Addressing
In dIVI, there is no need to allocate IVI6 address explicitly to end
users. Thus, the process of IPv6 address assignment can be integrated
with existing IPv6 address allocation process. Only CPE will need to
get IVI4 address, reallocate it to end user, do port-mapping and
traffic translation with port-related information. Here are some
basic considerations in dIVI addressing:
o Determine IVI6 prefix for each Xlate. Operators should use its own
prefix as an IVI6 prefix, i.e. pref=2001:db8:a4a6::/48, in order
to perform stateless translation. Address allocation process in
BRAS/SR should be consistent with Xlate.
o Determine the embedded IVI4 address and port multx ratio.
Operators should estimate the scale of subscribers in a certain
region, evaluate the number of remaining IPv4 address, and analyze
the number of concurrent ports. It is a tradeoff between multx
ratio and concurrent port numbers. The bigger the multx ratio is,
the more an IPv4 address can be shared by multiple subscribers and
the less concurrent port number can be used per subscriber. From
the above test in our laboratory, we choose multx ratio to be 128
and it is enough for current usage.
Sun Expires September 6, 2011 [Page 12]
Internet-Draft Considerations for Stateless Translation March 2011
o Determine the ways to distribute the configuration profile
including IVI4 address and port multx ratio to Hgw automatically,
either by extended DHCP option, or other protocols.
6.2. Routing
In dIVI, IVI4(i) and IVI6(i) will be aggregated to ISP's IPv4 address
and ISP's IPv6 address. They will not affect the global IPv4 and IPv6
routing tables
In dIVI deployment model, Hgws are normally configured with a default
route that points to the BRAS/SR. The routers between BRAS/SR and
Xlate run IPv6 dynamic routing protocols (IGP or BGP), and routers in
the upper level of Xlate run IPv4 dynamic routing protocols.
Therefore, the aggregated IVI6 routing directing to the upper routers
will be learned/inserted by in IPv6-only domain. And the IVI6 route
directing to Hgws should also be configured in BRAS/SR.
6.3. DNS
In dIVI, there is no DNS64/DNS46 needed anymore. An IPv6 DNS server
is needed to process IPv6 DNS request/response, and the address of
IPv6 DNS server should be passed to Hgw.
Since there is no IPv4 DNS server in IPv6-only network, it is
recommended that Hgw should implement IPv4-to-IPv6 DNS Proxy to
convert an IPv4 DNS request/response to IPv6 DNS request/response
accordingly.
6.4. AAA and User Management
User authentication can be used to control who can have the dIVI
connectivity service. This is not always required when a customer of
IPv4 service automatically can have access to the dIVI service.
However, it is highly recommended that IPv6-only customers should be
authenticated separately. It is good for security, trouble shooting,
user accounting, etc. There are some major points that AAA systems
need to be taken into consideration:
o User authentication function needs to be extended to support the
identification of IPv6-only subscriber, with additional dIVI-
related profile for subscribers, e.g. IVI6 address, IVI4 address,
non-IVI address, etc.
o User accounting and management function needs to be extended to
identify dIVI user (or IPv6-only user) separately.
Sun Expires September 6, 2011 [Page 13]
Internet-Draft Considerations for Stateless Translation March 2011
In summary, the major challenge of dIVI for the AAA and User
Management is no big difference compared to an IPv6-only environment.
6.5. Network management
There are two issues to manage dIVI in operational network:
o Manage IPv6-only network. Operators should be able to manage IPv6-
only network, including IPv6 MIB modules, Netflow Records, log
information, etc.
o Manage the translation process. There are some exceptions that the
MIB modules need to add dIVI related features, e.g. dIVI device
management, dIVI traffic monitoring, etc.
6.6. dIVI CPE Requirements and Configuration
In dIVI, CPE is an important network element. It should perform DHCP
server, integrated user authentication function, traffic translation
and port mapping, DNS proxy, etc. The major operations in dIVI CPE
include:
o Address assignment: dIVI CPE should support IVI4 address
assignment by DHCP process to end users. It should also support
IPv6 address assignment, either by stateful DHCP or stateless
auto-configuration.
o Integrated user authentication function: dIVI CPE should integrate
with existing user authentication function, e.g. PPPoE/PPPoA, etc.
o DNS: CPE should enable RFC 5006, well-known addresses, and DHCPv6
in order to maximize the likelihood of dIVI Hgw being able to use
DNS without manual configuration. Besides, dIVI CPE should also
support IPv4-to-IPv6 DNS proxy.
6.7. dIVI Xlate Placement in Large SP Network
Normally, dIVI Xlate can be deployed in "centralized model" and
"distributed model".
In "centralized model", dIVI Xlate could be deployed in the place of
Core Router, or even in the entrance of ICP. Since dIVI is a
stateless method with better scalability than stateful ones, it can
handle numerous concurrent sessions.
In "distributed model", dIVI Xlate is usually be integrated with
BRAS/SR. So each Xlate should be configured with its own IVI6 prefix
Sun Expires September 6, 2011 [Page 14]
Internet-Draft Considerations for Stateless Translation March 2011
and is responsible for translating the traffic of its own region. The
number of subscribers is normally limited, so does the number of IVI
routing entries. However, the network infrastructure should still be
upgraded to dual-stack support in MAN and backbone network, and so
the decreased operational cost is rather limited. Besides, since the
newly emerging customers might be distributed in the whole Metro area,
we have to deploy Xlate on all BRAS/SRs. This will cost a lot in the
initial phase of IPv6 transition period.
In summary, we strongly recommend adopting "centralized model" for
dIVI. It is a cost-effective way and easy to manage.
6.8. ALG consideration
dIVI does not require ALG, this is a very important feature in the
initial development phase of IPv6.
7. Security Considerations
There are no security considerations in this document.
8. IANA Considerations
This memo adds no new IANA considerations.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
9. References
9.1. Normative References
[I-D.ietf-behave-address-format] C., Bao, Huitema, C., Bagnulo, M.,
Boucadair, M., and X.Li, "IPv6 Addressing of IPv4/IPv6
Translators", draft-ietf-behave-address-format-10 (work in
progress), August 2009.
[I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and
I. Beijnum, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", draft-ietf-
behave-dns64-11 (work in progress),October 2009.
Sun Expires September 6, 2011 [Page 15]
Internet-Draft Considerations for Stateless Translation March 2011
[I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K.
Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-
behave-v6v4-framework-10 (work in progress), October 2009.
[I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP
Translation Algorithm", draft-ietf-behave-v6v4-xlate-23
(work in progress), October 2009.
[I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., I.
Beijnum, "IP/ICMP Translation Algorithm", draft-ietf-
behave-v6v4-xlate-12 (work in progress), October 2009.
[I-D.xli-behave-divi] Li,X., Bao, C., and Zhang, H., "Address-sharing
stateless double IVI", draft-xli-behave-divi-01, April 29,
2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Acknowledgments
The authors would like to thank to Fred Baker for his continuous
suggestion around this topic over the years. Thanks to Qian Wang, Jie
Hu and Fan Shi for useful feedback.
Sun Expires September 6, 2011 [Page 16]
Internet-Draft Considerations for Stateless Translation March 2011
Authors' Addresses
Qiong SUN
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
China
Phone: <86 10 58552636>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
China
Phone: <86 10 58552116>
Email: xiechf@ctbri.com.cn
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Phone: <86 10 62785983>
Email: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Phone: <86 10 62785983>
Email: congxiao@cernet.edu.cn >
Ming Feng
China Telecom
No.31, Jinrong Ave,Xicheng District,100032
Phone: <86 10 58501428>
Email: fengm@chinatelecom.com.cn
Sun Expires September 6, 2011 [Page 17]