Internet Engineering Task Force C. Sun
Internet-Draft Softbank BB
Intended status: Informational S. Matsushima
Expires: September 16, 2011 Softbank Telecom
J. Jiao
Softbank BB
March 15, 2011
4rd Applicability Statement
draft-sun-intarea-4rd-applicability-01
Abstract
This document discusses the applicability of the IPv4 Residual
Deployment (4rd) protocol, and an address sharing mechanism, NAT44 on
4rd CE side, and routing optimization to provide IPv4 connectivity in
4rd capable IPv6-only networks.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 16, 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
Sun, et al. Expires September 16, 2011 [Page 1]
Internet-Draft 4rd Applicability March 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of 4rd . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. IPv4 Address Assignment . . . . . . . . . . . . . . . . . 4
3.2. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . . 5
3.3. Distributing NAT function to CEs . . . . . . . . . . . . . 7
3.4. Routing optimization to provide IPv4 connectivity . . . . 9
3.5. Gateway Redundancy Considerations . . . . . . . . . . . . 10
3.6. NAT Log Considerations . . . . . . . . . . . . . . . . . . 11
4. Constraint Considerations . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Sun, et al. Expires September 16, 2011 [Page 2]
Internet-Draft 4rd Applicability March 2011
1. Introduction
The Internet continues to grow beyond the capabilities of IPv4. The
tremendous success of the Internet has strained the address space,
which is no longer sufficient to support future growth. The IANA
free pool of IPv4 address have been depleted already. With its
increase in the number of available prefixes and addresses in a
subnet, and improvement in address management, IPv6 is the only real
option on the table. During the long transition period from only
IPv4 to IPv6, the networks of Internet Service Providers (ISPs) will
have to offer more than just IPv6 connectivity. Both outgoing and
incoming connections will have to be supported.
IPv4 Residual Deployment (4rd) enables a service provider to share
IPv4 addresses among its customers by combining the well-known
technologies of stateless address mapping and tunneling, NAT44, and
IPv4 in IPv6 encapsulation.
This document discusses the applicability of the 4rd protocol, and an
address sharing mechanism, NAT44 on 4rd CE side, and routing
optimization to provide IPv4 connectivity in 4rd capable IPv6-only
networks.
2. Overview of 4rd
If 4rd [I-D.despres-intarea-4rd] is to be actually used across a
IPv6-only network to offer IPv4 connectivity
[I-D.arkko-ipv6-transition-guidelines], the network must have 4rd
Border Relay Router (BR) and 4rd Customer Edge Router (CE).
With 4rd, we need not worry that well-known (reserved) IPv4 addresses
(such as 000/8) are generated, because all 4rd CEs generating IPv4
addresses are in the range of domain 4rd prefix. (Section 3.1). The
4rd model is built on IPv4 over IPv6 stateless tunnels to reach 4rd
CEs where customers will share IPv4 addresses if the CE 4rd prefix is
longer than 32-bits (Section 3.2). 4rd differs from other solutions
such as Dual-Stack-lite [I-D.ietf-softwire-dual-stack-lite] since the
4rd CE is used to implement the NAT44 (Section 3.3). 4rd also can
implement Routing Optimization to Provide IPv4 Connectivity while the
4rd CE communicates with other 4rd CE (Section 3.4).
3. Applicability
In this section, we describe 4rd applicability with Figure 1 as an
example of 4rd enabled network. It is helpful to explain 4rd and
underdtand 4rd applicability.
Sun, et al. Expires September 16, 2011 [Page 3]
Internet-Draft 4rd Applicability March 2011
+------------------------+
/ \
| IPv4 Internet |
\ /
+------------------------+
|
|
+----------------------+
| 4rd BR |
+----------------------+
|
|
+ --------------------------------+
/ \
| ISP's IPv6 network |
\ 2001:db8::/32 /
---------------------------------
/ | \
/ | \
/ | \
2001:db8:cdab::/48 2001:db8:cdef::/48 2001:db8:cda1::/48
+-----------+ +------------+ +------------+
| 4rd CE1 | | 4rd CE2 | *** | 4rd CEn |
+-----------+ +------------+ + -----------+
Figure 1: A 4rd network model example
3.1. IPv4 Address Assignment
[I-D.despres-intarea-4rd] specify 4rd address mapping rule. When 4rd
address mapping rule apply to the Figure 1, as Figure 2 shown, a 4rd
CE1's IPv4 address, which is in the range of domain 4rd prefix, is
generated from CE IPv6 prefix. As the prerequisite of 4rd, Domain
IPv6 prefix and Domain 4rd prefix must be given to all 4rd CEs and
4rd BRs in a specified 4rd domain. CE IPv6 prefix for all 4rd CEs in
the specified 4rd domain must be in same Domain IPv6 prefix but must
be unique for each 4rd CE.
Sun, et al. Expires September 16, 2011 [Page 4]
Internet-Draft 4rd Applicability March 2011
<------------ CE IPv6 prefix (max length 64) ------------>
+-------------------------------+-------------------------+
| 2001:db8::/32 | 0xcdab |
+-------------------------------+-------------------------+
<-- Domain IPv6 prefix length --|<----CE index length---->|
: || :
Domain 4rd prefix : \/ :
|<----------------->|<-- suffix-->| |
+-------------------+-------------------------+
CE 4rd prefix | 192.0.2.0/24 | 0xcd | 0xab |
+-------------------+-------------------------+
|<----4rd CE1's IPv4 address----->|<--------->|
192.0.2.205(0xcd) Port-set ID
Figure 2: An example of 4rd address mapping for 4rd CE1
All 4rd CEs IPv4 addresses are in the range fo domain of domain 4rd
prefix. Figure 2 shows an example that 4rd CE1's IPv4 address how to
be genarated. This means that it is not necessary for 4rd operators
to pay attention to what IPv4 address is generated by 4rd CE. In the
case of all 32 bits of IPv4 address is mapped to IPv6 prefix, 4rd CE
must not generate well-known IPv4 address (such as 0/8, 127/8, etc.,
for example) so that IPv6 prefix assignment should be taken careful
to avoid it. 4rd is recommended to operators who do not want IPv6
prefix assignment of which takes into account what IPv4 address
generated from IPv6 prefix.
As example (Figure 1) shown, the 4rd model is built on IPv4 over IPv6
tunnels to reach 4rd CEs where up to 256 customers can share a IPv4
addresse. In the given example, the IPv6 ISP aggregate Domain IPv6
prefix is 2001:db8::/32. Out of this aggregate, a /48 CE IPv6 prefix
for each 4rd CE is assumed to be issued, this allowing for a 16-bits
CE index. Since remaining bits to mapping IPv4 address is 8 bit,
"0xab" is a part of last octet of CE1's IPv4 address. As a result,
192.0.2.205 is shared with 256 4rd-CEs.
3.2. IPv4 Address Sharing
When the CE 4rd prefix is longer than 32 bits, IPv4 address will be
shared by muliple 4rd CEs. As Figure 3 shown, the suffix of shared
IPv4 address and Port-set ID are derived from CE index of CE IPv6
prefix. CEs have same 4rd shared IPv4 address and unique Port-set
ID, so CEs can be identified using IPv4 address and unique Port-set
ID.
Sun, et al. Expires September 16, 2011 [Page 5]
Internet-Draft 4rd Applicability March 2011
<------------ CE IPv6 prefix length (max 64) ------------->
+-------------------------------+-------------------------+
| 2001:db8::/32 | CE index |
+-------------------------------+-------------------------+
<-- Domain IPv6 Prefix length --|<----CE index length---->|
: || :
Domain 4rd prefix : \/ :
|<----------------->|<-- suffix-->| |
+-------------------+-------------------------+
CE 4rd prefix | 192.0.2.0/24 | 0xcd |Port-set ID|
+-------------------+-------------------------+
|<---4rd shared IPv4 address----->| CE1: Oxab
192.0.2.205(0xcd) CE2: Oxef
... ...
CEn: Oxa1
Figure 3: Port-set ID generation example
As shown in Figure 3 , the available port-set ID for IPv4 address
sharing is derived form the remaining 8-bits, e.g. 0xab, 0xef, 0xa1
used by 4rd CE1, 4rd CE2, 4rd CEn respectively. With this particular
scheme shown in the example, up to 256 4rd CEs can share the IPv4
address.
According to [I-D.despres-intarea-4rd],each 4rd CE has its unique
port-ranges which is calculated based on the 4rd mapping rule with
their Port-set ID. The 4rd port mapping rule uses four heads, as
shown in the Figure 4 below. This allows 4rd CEs to avoid using well
known (reserved) TCP/UDP ports 0-4095.
Sun, et al. Expires September 16, 2011 [Page 6]
Internet-Draft 4rd Applicability March 2011
<------- Port (16bit) ---------->
Port-range a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(head=0001) |0|0|0|1|1 0 1 0|1 0 1 1| | 0x1AB0 - 0x1ABF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 0xA / 0xB /
Port-range b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(head=001) |0|0|1|1 0 1 0|1 0 1 1| | 0x3560 - 0x356F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 0xA / 0xB /
Port-range c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(head=01) |0|1|1 0 1 0|1 0 1 1| | 0x6AC0 - 0x6AFF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 0xA / 0xB /
Port-range d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(head=1) |1|1 0 1 0|1 0 1 1| | 0xD570 - 0xD5FF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 0xA / 0xB /
Port-set ID +-+-+-+-+-+-+-+-+
(CE1,0xAB) |1 0 1 0|1 0 1 1|
+-+-+-+-+-+-+-+-+
Figure 4: Port-range calculation example for 4rd CE1
3.3. Distributing NAT function to CEs
Since 4rd distributes NAT44 function to the 4rd CE, the CE side NAT44
manages user's NATed session in general of each 4rd CE unit.
According to their own infrastructure and management systems, if ISPs
think 4rd CE Side NAT is easier to manage than gateway side NAT, they
can adopt the 4rd technology.
The capex and opex costs of an ISP vary from network to network. The
4rd solution is an ideal fit for those where a CE based NAT solution
is acceptable, and where investment in operating and managing of a
centralized NAPT 44 gateway is not desired.
For an CE IPv6 prefix of a given length, e.g. a /56 PD, as more and
more bits are used to express the shared IPv4 address, the less bits
are available to express the port range. It is not 4rd specific
issue, but a method that supports NAT Port Mapping needs to be
devised. For example, 256 ports can be used by 4rd CE, but access to
host A, B, and C requires 100 ports each. If the 4rd CE ports are
distributed when A,B,C are accessed at the same time from the same
4rd CE, Ports 0 - 99 are used to access host A, Ports 100 - 199 are
used to access host B, but host C cannot be accessed because the
remaining ports are not enough. As Figure 5, 4rd can reuse the 4rd
CE Port by terms of recognizing the destination addresses in order to
reduce the aspect of this problem. It is noted that the problem can
Sun, et al. Expires September 16, 2011 [Page 7]
Internet-Draft 4rd Applicability March 2011
not be solved if the multiple users under same 4rd CE access the same
host (e.g. host A) exceed the number of ports.
-----------------------------------
/ \
/ IPv4 Internet \
| +--------+ +--------+ +--------+ |
\ | host A | | host B | | host C | /
\ +--------+ +--------+ +--------+ /
--------------------------------------
|
+---------------------+
| 4rd BR |
+---------------------+
|
+---------------------------------+
/ \
| ISP's IPv6 network |
\ /
+---------------------------------+
|
4rd CE |
+--------------------------------------------------+
| Port number Port number Port number |
| pool for pool for pool for |
| +--host A --+ +--host B --+ +--host C --+ |
| | Port0-255 | | Port0-255 | | Port0-255 | |
| +-----------+ +-----------+ +-----------+ |
+--------------------------------------------------+
Figure 5: Reuse port number on 4rd CE side NAT
Figure 6 quantifies address sharing rates for different port range
lengths, along with the overall number of ports available to a give
CE. The 4rd allows 16 bits to be used by NAPT. In theory, one IPv4
address can be shared by 65536 (2 to 16th power) customers. However,
at least 1 bit is needed for Port-range Index. The greatest bit
range that can be used to share address are 15 bits.
Sun, et al. Expires September 16, 2011 [Page 8]
Internet-Draft 4rd Applicability March 2011
+------------+-------------------------+---------------+------------+
| Port | User numbers that can | # of ports | Relative |
| prefix | share one v4 address | for a 4rd CE | to a /8 |
| length | | | |
+------------+-------------------------+---------------+------------+
| 1 | 1 - 2 | 30720 | /9 |
| 2 | 1 - 4 | 15360 | /10 |
| 3 | 1 - 8 | 7680 | /11 |
| 4 | 1 - 16 | 3840 | /12 |
| 5 | 1 - 32 | 1920 | /13 |
| 6 | 1 - 64 | 960 | /14 |
| 7 | 1 - 128 | 480 | /15 |
| 8 | 1 - 256 | 240 | /16 |
| 9 | 1 - 512 | 120 | /17 |
| 10 | 1 - 1024 | 60 | /18 |
| 11 | 1 - 2048 | 30 | /19 |
| 12 | 1 - 4096 | 15 | /20 |
| 13 | 1 - 8192 | 7 | /21 |
| 14 | 1 - 16384 | 3 | /22 |
| 15 | 1 - 32768 | 1 | /23 |
+------------+-------------------------+---------------+------------+
Figure 6: 4rd CE available port
3.4. Routing optimization to provide IPv4 connectivity
Figure 7 shows that 4rd can implement IPv6 routing with direct IP
forwarding between the two 4rd CEs. In other words, 4rd allows
direct packet forwarding between CEs that share a 4rd domain, without
the need of forwarding such traffic through the gateway.
When V4a under 4rd CE1 send packets to V4b under 4rd CE2, the packets
need not go through the gateway (Hub&Spoke) before going to 4rd CE2,
they can go to 4rd CE2 directly (mesh). This section describes this
in more detail from two perspectives: Network matching and Network
Load.
Sun, et al. Expires September 16, 2011 [Page 9]
Internet-Draft 4rd Applicability March 2011
+------------------------+
/ IPv4 Network \
\ /
+-------------------------+
|
+---------------------+
| gateway (e.g. BR) |
+---------------------+
|
+------------------------+
/ \ +----------------------+
| ISP's IPv6 access NW | -------| 4rd CE2 (V4b) |
\ [//]===/========+== >------------------+
+-----------------[//]---+
| [//]
+---------------[//]---+
| 4rd CE1 (V4a) |
+----------------------+
Figure 7
Taking network matching into account, 4rd should be chosen if the
ISP's IPv6 network allows direct CE-CE traffic forwarding (eg: IPv6
Flat Routing Network).
Compared to Hub & Spoke architecture solutions, mesh architecture
solutions can achieve a smaller network load when the 4rd CE
communicate frequently. If the ISP thinks that its network has
insufficient bandwidth or it wants to lower the load imposed by IPv4
connections, they should choose a mesh architecture solution such as
4rd.
Note: Softwire mesh [RFC5565] is also a mesh architecture solution,
but it does not provide the IPv4 sharing function. Softwire mesh can
be adopted if IPv4 address sharing is not needed.
3.5. Gateway Redundancy Considerations
Since in 4rd the BR side does not implement the NAT function, the BR
can be easily replicated. For instance, there can be N:1 redundant
BRs in the network. Reliable network operation can be guaranteed
because a failed BR can be immediately and easily replicated by any
one of the N BRs.
If the gateway side implements NAT, 1:1 gateway redundancy is the
choice, and also upstream and downstream traffic from the same user
must go through the same gateway. 4rd easily realizes load balancing
because upstream and downstream traffic from the same user can go
Sun, et al. Expires September 16, 2011 [Page 10]
Internet-Draft 4rd Applicability March 2011
through different gateways.
3.6. NAT Log Considerations
4rd CE uses fixed NAT rules and IPv4 users can be directly identified
by means of their IPv6 address, so the NAT log does not need to be
left. In other words, 4rd allows an operator to save on the need to
perform NAT log collection and retention. On the other hand, other
solutions may achieve higher address sharing rate than 4rd. If
operators want to reduce NAT log with these solutions, their NATs
have to be configured with [I-D.tsou-behave-natx4-log-reduction], or
allocate fixed port range for NAT rules regardless of the advantage.
It is noted that another logging necessity coming from
[I-D.ietf-intarea-shared-addressing-issues] is described in
[I-D.ietf-intarea-server-logging-recommendations] for Internet facing
servers.
4. Constraint Considerations
This section describes the constraint on user number when addresses
are shared. As Section 3.3 stated, the maximum bit range that can be
used by Port-set ID is 15 bits. In this case, 4rd CE is restricted
to one private port. In fact, it is not able to provide service. So
the customer numbers per IPv4 address that can be shared need to be
considered along with the ports needed by 4rd CE.
It is noted that deriving IPv4 addresses from CE IPv6 prefix
generated by 4rd mapping rule may lead to a low rate of IPv4 address
sharing because it does not allow for statistical multipexing gains.
ISPs who feel that this is not desirable and want to achieve high
sharing rates can select centralized gateway/NAPT solutions, which
can have a high sharing rate because allow for such statistical
multipexing gains.
5. Security Considerations
The sharing of IPv4 address reduces the port selection space per 4rd
CE, so a blind attack can be performed easily. An attack can be
performed if the attacker is able to correctly guess the source
address and source port. Address and Port Dependent Filtering (APDF)
need be implemented in order to counter blind attack. In APDF, not
only source address and source port but also destination address and
destination port need to be checked. Even so, a blind attack that
can be performed against TCP relies on the attacker's ability to
guess the 5-ruple (Protocol, Source address, Destination address,
Sun, et al. Expires September 16, 2011 [Page 11]
Internet-Draft 4rd Applicability March 2011
Source Port, Destination Port). Shared address issues
[I-D.ietf-intarea-shared-addressing-issues] describes a method for
the random selection of TCP Sequence Number, that reduces the ability
of attacker to correctly guess the 5-ruple.
DNS is one of the important protocols to use UDP. In 4rd CE, all DNS
reply packets should be discarded, expect for the packets from
forward destinations. If DNS implements Port Randomization, the
attack success rate can be reduced.
We describe here a method for reducing Spoofing Attack under 4rd CE.
Using the 4rd mapping rule, the IPv4 address can be derived from IPv6
address, so we can check the IPv4 address thus derived and the IPv4
address in the header of received packet. If they are same, the
packet is forwarded, otherwise, it is dropped.
6. Conclusions
This document described the ability of 4rd to support the IPv6-only
access network. We conclude that the 4rd solution is a viable choice
when the ISP desires a stateless IPv4 address sharing option, based
on CE side NAT functionality, along with a high degree of freedom in
terms of redundancy and optimal traffic forwarding. 4rd is also
recommended to operators who do not want IPv6 prefix assignment of
which takes into account what IPv4 address generated from IPv6
prefix. When only one 4rd applicable character is needed, 4rd may be
used to only that purpose with other solutions.
7. Acknowledgements
The authors would like to thank Remi Despres for his enormous effort
to work for 4rd architecture and protocol. The authors also thank to
people who provided encouragements concerning the 4rd approach and
lead to consider 4rd in Japan. In particular, we would like to thank
Toshiya Asaba, Yoshiki Ishida, Tetsuya Innami, Ruri Hiromi, Masataka
Mawatari, Akira Nakagawa, Tomoyuki Sahara, Taisuke Sasaki, Katsuyasu
Toyama, Mark Townsley, Wojciech Dec, Yuji Yamazaki, have provided
useful discussion and comments on the document and review.
8. References
8.1. Normative References
[I-D.despres-intarea-4rd]
Despres, R., Matsushima, S., Murakami, T., and O. Troan,
Sun, et al. Expires September 16, 2011 [Page 12]
Internet-Draft 4rd Applicability March 2011
"IPv4 Residual Deployment across IPv6-Service networks
(4rd) ISP-NAT's made optional",
draft-despres-intarea-4rd-00 (work in progress),
March 2011.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
8.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[I-D.ietf-intarea-server-logging-recommendations]
Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging recommendations for Internet facing servers",
draft-ietf-intarea-server-logging-recommendations-03 (work
in progress), February 2011.
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-05 (work in
progress), March 2011.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
in progress), March 2011.
[I-D.tsou-behave-natx4-log-reduction]
ZOU), T., Li, W., and T. Taylor, "Port Management To
Reduce Logging In Large-Scale NATs",
draft-tsou-behave-natx4-log-reduction-02 (work in
progress), September 2010.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Sun, et al. Expires September 16, 2011 [Page 13]
Internet-Draft 4rd Applicability March 2011
Reserved for Documentation", RFC 3849, July 2004.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
Authors' Addresses
Chunfa Sun
Softbank BB
Tokyo Shiodome Building. 22F
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: c-sun@bb.softbank.co.jp
Satoru Matsushima
Softbank Telecom
Tokyo Shiodome Building. 22F
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: satoru.matsushima@tm.softbank.co.jp
Jie Jiao
Softbank BB
Tokyo Shiodome Building. 12F
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: j-jiao@bb.softbank.co.jp
Sun, et al. Expires September 16, 2011 [Page 14]