Internet DRAFT - draft-sun-softwire-stateless-4over6
draft-sun-softwire-stateless-4over6
Network Working Group Q. Sun
Internet-Draft C. Xie
Intended status: Standards Track China Telecom
Expires: March 28, 2012 Y. Cui
J. Wu
P. Wu
Tsinghua University
C. Zhou
Huawei Technologies
Y. Lee
Comcast
September 25, 2011
Stateless 4over6 in access network
draft-sun-softwire-stateless-4over6-00
Abstract
This document specifies a stateless 4over6 mechanism which moves the
translation function from tunnel concentrator (AFTR) to initiators
(B4s). It is used for service providers offering residual deployment
of the IPv4 service across IPv6-only domains. The concentrator will
record the full set of prefix mapping rules independent of the number
of subscribers, while the initiator will only keep a single rule of
its own sub-domain. The BNG devices can learn the rule set further,
to achieve traffic optimization between initiators. In this way, it
not only achieve scalability and simplicity feature benefits from
stateless address mapping, but also keep CPE functions simple.
Besides, flexible addressing and scattered IPv4 address blocks can be
supported as well. Traffic optimization can be deployed
incrementally when necessary.
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."
Sun, et al. Expires March 28, 2012 [Page 1]
Internet-Draft stateless 4over6 September 2011
This Internet-Draft will expire on March 28, 2012.
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.
Sun, et al. Expires March 28, 2012 [Page 2]
Internet-Draft stateless 4over6 September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Stateless 4over6 Overview . . . . . . . . . . . . . . . . . . 8
5. Port Restricted IPv4 Address Allocation . . . . . . . . . . . 10
6. Address/Prefix Mapping . . . . . . . . . . . . . . . . . . . . 11
6.1. Address/Prefix Mapping format . . . . . . . . . . . . . . 11
6.2. Address/Prefix Mapping Procedure . . . . . . . . . . . . . 11
6.3. Port mapping algorithm . . . . . . . . . . . . . . . . . . 12
7. Stateless 4over6 Initiator Behavior . . . . . . . . . . . . . 13
8. Stateless 4over6 Concentrator Behavior . . . . . . . . . . . . 14
9. CPE-CPE optimization . . . . . . . . . . . . . . . . . . . . . 15
10. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Sun, et al. Expires March 28, 2012 [Page 3]
Internet-Draft stateless 4over6 September 2011
1. Introduction
Global IPv4 address exhaustion is becoming reality. The dramatic
growth of the Internet is accelerating the consumption of available
IPv4 addresses together with the scattered IPv4 address blocks, which
makes the address shortage problem even worse. It is widely accepted
that IPv6 is the only answer to solve the address shortage problem
and sustain the long-term growth of the Internet. However, IPv6
deployment is a huge systematic project and a lot of challenges will
arise, especially in large commercial operational network.
In the course of IPv6 transition, CPE is always a big issue for the
whole industry. Since CPE is a customer-side device with restricted
resource, it is cost sensitive. Moreover, there is lots of legacy
CPEs which are owned by customers, in this case, ISP can not upgrade
them . Besides, due to the huge number of CPEs, it is of vital
importance to keep it simple for easy management and trouble
shooting.
As discussed in [I-D.ietf-softwire-stateless-4v6-motivation],
stateless approaches would have good features of high scalability,
reliability and robustness, etc. It is easy to achieve multi-vendor
redundancy. However, since stateless solutions have essentially
infered the mapping relationship between IPv4 address and IPv6
address, it would have some kind of impact on network planning, e.g.
address planning, routing, CPE, etc. From service provider
perspective, there are several operational requirements on stateless
approaches.
Firstly, flexible addressing is needed especially when the remaining
IPv4 address blocks are rather scattered. Network providers might do
address reallocation in their network in the future, e.g. reallocate
global IPv4 address for address sharing. And this kind of addressing
adjustment need to have little impact on the whole network
infrastructure, e.g. informing thoudsands of CPEs within the same
domain.
Secondly, we need to keep CPE as simple as possible. This will not
only reduce the great burden on CPE management and trouble shooting,
but also reduce cost and implemenation complexity.
Thirdly, stateless solutions should be capable of covering a large
area with centralized deployment. Since stateless approaches can
achieve high scalability and no performance bottleneck, centralized
deployment is good for network management and multi-vendor industry.
Given the fact that large scale service providers would normally have
few thousand BNGs with different vendors and different versions, it
is a huge burden to update all existing BNGs with the new service
Sun, et al. Expires March 28, 2012 [Page 4]
Internet-Draft stateless 4over6 September 2011
card.
Finally, CPE-CPE traffic optimization should be deployed
incrementally. Currently, network architecture for some service
providers is already rather flat, and there is no direct link between
CPEs. The traffic within the same BNG occupies a small percentage,
so CPE-CPE traffic optimization is NOT a MUST in general. It can be
only deployed incrementally when necessary.
In this document, we propose a stateless 4over6 approach for service
providers offering residual deployment of the IPv4 service across
IPv6-only domains. In stateless 4over6, the concentrator will record
the full set of prefix mapping rules including IPv4 prefix, IPv6
prefix and multiplexing ratio, while the initiator will only keep a
single rule of its own sub-domain. Thus, all traffic will be firstly
tunneled to concentrator by default. The BNG devices can learn the
rule set further, to achieve traffic optimization between initiators.
This procedure keeps the advantages of stateless 4over6 mechanisms,
and prevents the customer devices from complex configuration/
delegation. It "moves" the mapping rules from customer devices up to
concentrator and BRAS devices, in which the amount of rules is
acceptable. It can still keep the flexible feature of centralized
addressing. This is also an extended case which covers stateless
addressing sharing for [I-D.cui-softwire-host-4over6]. However, this
extension will decrease IPv4 address utilization. Moreover, since
port randomization algorithm must use ports within this port-range,
it may cause the port randomization algorithm more predictable.
Sun, et al. Expires March 28, 2012 [Page 5]
Internet-Draft stateless 4over6 September 2011
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Sun, et al. Expires March 28, 2012 [Page 6]
Internet-Draft stateless 4over6 September 2011
3. Terminology
Stateless 4over6: stateless 4over6 is an IPv4-over-IPv6 hub and spoke
mechanism proposed in this document, which supports address sharing
to alleviate the problem of IPv4 address exhaustion, and places the
IPv4 translation on the initiator side.
Stateless 4over6 initiator (or "initiator" for short): the tunnel
client module of stateless 4over6 mechanism. The stateless 4over6
initiator could be a host directly connected to IPv6, or an dual-
stack CPE in front of an IPv4 local network. It is responsible for
IPv4 public-private translation besides tunnel encapsulation and
decapsulation.
Stateless 4over6 concentrator (or "concentrator" for short): the
tunnel servicing module in stateless 4over6 mechanism. The stateless
4over6 concentrator connects the ISP IPv6 network and IPv4 Internet.
It provides tunnel encapsulation and decapsulation but no IPv4
private-public translation.
Stateless 4over6 domain(or "SL Domain" for short): The IPv6 network a
concentrator covers. Its coverage depends on the placement of the
concentrator. For example, if the concentrator is deployed at the
Core of MAN, the Domain will cover the whole MAN.
Stateless 4over6 sub-domain(or "sub-domain" for short): A IPv6 sub-
network where different initiators can share a same IPv4/IPv6 prefix
for stateless mapping. It usually depends on the range of IPv4
address block and multiplexing ratio.
Stateless 4over6 subPre6(or "subPre6" for short): A common IPv6
prefix in the sub-domain for stateless address mapping. subPre6 is
only a part of IPv6 perfix/address delegated to customers, which will
be followed by "user-id" , etc.(refer to section 6 for detail).
Stateless 4over6 subPre4(or "subPre4" for short): A common IPv4
prefix in the sub-domain for stateless address mapping. Different
subscribers in the common sub-domain will have a different identifier
(indicated by "Free bits"). For example, if a given subPre4 is
"202.112.1/24" and the shared public address for the specific
subscriber is "202.112.1.5", then the "Free bits" is "5".
Stateless sub-domain Rule(or "sub-domain rule" for short): A mapping
rule inculding subPre6, subPre4 and Multiplexing ratio for a specific
sub-domain.
Sun, et al. Expires March 28, 2012 [Page 7]
Internet-Draft stateless 4over6 September 2011
4. Stateless 4over6 Overview
Figure 1 provides an overview of the stateless 4over6 mechanism. A
stateless 4over6 initiator which can be either an IPv6 hosts or CPE,
and the stateless 4over6 concentrator are seperated by the IPv6
network in the middle, so they use IPv4-in-IPv6 tunnel to build IPv4
connectivity. One concentrator will cover a SL Domain and there will
be one or more sub-domains in it. Each sub-domain will only have one
sub-domain rule indicating the common subPre6, subPre4 and
multiplexing ratio. These sub-domains can be divided in a rather
flexible way. One BNG can have one or more sub-domains, and multiple
BNGs can also belong to one sub-domain. The only rule for sub-domain
to follow is to have a unique sub-domain rule with a unified
multiplexing ratio.
+------------------------------+
| Stateless 4over6 Domain |
+---+---------------+--------------|
+--------+ + Sub-domain | |
| | +---------+ +--+--+ |
|IPv4 LAN|--|SL 4over6| | | |
| | |Initiator|======| BNG | ======+---------+ +-----------+
+--------+ +---------+ +--|--+ |SL 4over6| | IPv4 |
+--------+ +---------------+ |Concen- |---| Internet |
| | +---|-----+ +--+--+ |trator | | |
|IPv4 LAN|--|SL 4over6|======| | ======+---------+ +-----------+
| | |Initiator| | BNG | |
+--------+ +---------+ +--+--+ |
+ Sub-domain | |
+-------------------+--------------+
Figure 1 Stateless 4over6 overview
An initiator will get its sub-domain rule containing subPre6, subPre4
and multiplexing ratio. And it will also get a user prefix which
includes a user-id via PPPoE, etc. By combining the user-id and
multiplexing ratio, we can deduce the vaule of the "Free bits" and
"Port-set id". SubPre4 and "Free bits" will then construct a public
address for the customer, while "Port-set id" can be mapped to a
certain port set by port mapping algorithm.
In this way, an initiator has known its shared IPv4 address and valid
port range. For a IPv4 outbound packet arriving at initiator, it
will do port-restricted NAT44, then encapuslate with IPv6 header and
tunneled to the concentrator by default. The source address and
destination address format in IPv6 header will be discussed in the
next section. The concentrator will only do packet de-capsulation
for outbound packet. When the inbound traffic arriving at
Sun, et al. Expires March 28, 2012 [Page 8]
Internet-Draft stateless 4over6 September 2011
concentrator, it will lookup sub-domain rule table based on
destination IPv4 address and find out its corresponding subPre6.
Then it will construct an IPv6 header algorithmically. Since the
number of sub-domain rules is independent of subscriber numbers, it
is still a algorithm-based stateless method. Then the inbound
traffic will be sent back to customer and perform NAT44 again.
Sun, et al. Expires March 28, 2012 [Page 9]
Internet-Draft stateless 4over6 September 2011
5. Port Restricted IPv4 Address Allocation
As described above, a stateless 4over6 initiator needs the sub-domain
rule containing subPre6, subPre4 and multiplexing ratio. Since these
parameters are relatively stable, it can be configured in a variety
of provisioning methods, including
DHCPv6[I-D.cui-softwire-dhcp-over-tunnel], "TR-069", etc. For
customer's IPv6 prefix, it will be delegated just in traditional way,
e.g. DHCPv6, Prefix Delegation, etc. And there is no impact on
current IPv6 addressing model. The concentrator address can be
passed through the same option of ds-lite AFTR address.
Sun, et al. Expires March 28, 2012 [Page 10]
Internet-Draft stateless 4over6 September 2011
6. Address/Prefix Mapping
6.1. Address/Prefix Mapping format
The subscriber source address mapping format is in consistent with
[I-D.xli-behave-divi-pd] expect for the last 64 bits. Since
stateless 4over6 is a tunnel-based solution, we just set the last 64
bits to zero (depicted in Figure2).
+--+---------+-------+------+-----+----+-----------+-----------+----+
|PL| 0-------32------48-----56----64---72----------104---------120 |
+--+---------+-------+------+-----+----+-----------+-----------+----+
|64| prefix | u | 0 |
+--+---------+-------+------+-----+----+-----------+-----------+----+
|e | Prefix-sub |user(CPE)-id| 0 | u | 0 | 0 |
|x |-------------+------------+---+----+-----------+-----------+----|
|t |(d) bits |(s+k) bits |(m)|(8) | (48) |(8) |
+--+---------+-------+------+-----+----+-----------+-----------+----+
Figure 2 Subscriber Source address mapping format
The user-id is consisted of the "Free Bits" and "Port-set id".
The destination address is the concentrator address in CPE. However,
when BRAS is processing traffic optimization, the destination address
needs to be performed in a similar way with subscriber source
address.
6.2. Address/Prefix Mapping Procedure
+-----------------+---------+---+---------+---------+------------------+
|sub-doamin rule |subPref6 | |subPref4 | |Multiplexing Ratio|
+-----------------+---------+---+---------+---------+--------|---------+
|
+-------------------------------+---------+--------+---------|---------+
|IPv6 user prefix |subPref6 |user-id | | |
+-------------------------------+---------+----|---+---------|---------+
| |
+---------+ +------+------+
|subPref4 | | Free | Port |
| | | Bits |Set id|
+---+-----+ +--+---+---+--+
| / |
| / |
+---+-----+---+--+ +---+--+
|subPref4 | Free | | Port |
| | Bits | | Set |
+---------+------+ +------+
Sun, et al. Expires March 28, 2012 [Page 11]
Internet-Draft stateless 4over6 September 2011
Shared IPv4 address
Figure 2 Address/Prefix Mapping Procedure
The above figure depicts address mapping procedure in stateless
4over6. An initiator will get its sub-domain rule containing
subPre6, subPre4 and multiplexing ratio. And it will also get a user
prefix incluing subPref6 and user-id. By combining the user-id and
multiplexing ratio, we can deduce the vaule of the "Free bits" and
"Port-set id". SubPre4 and "Free bits" will then construct a public
address for the customer, while "Port-set id" can be mapped to a
certain "Port Set" by port mapping algorithm.
Detailed descriptions will be added soon...
6.3. Port mapping algorithm
A unified Port mapping algorithms should be defined to determine the
mapping rule between Port-set id and Port-set. You can refer to
[I-D.xli-behave-divi-pd] for example. And we will complete this
section soon ...
Sun, et al. Expires March 28, 2012 [Page 12]
Internet-Draft stateless 4over6 September 2011
7. Stateless 4over6 Initiator Behavior
When requiring IPv4 access, the initiator needs to get its IPv6
address/prefix via normal IPv6 address allocation precedure first,
then it will calculate its port-restricted IPv4 address and valid
port range.
The data plane functions of the initiator includes translation and
encapsulation/decapsulation. For CPE initiator case, the initiator
runs a standard local NAT44 with the address pool consist of the
calculated port restricted address. When sending out an IPv4 packet
with private source address, it performs NAT44 function and
translates the source address into public. Then it encapsulates the
packet with concentrator's IPv6 address as destination IPv6 address,
and forwards it to the concentrator. The source address of the IPv6
packet will be generated as described above. When receiving an IPv4-
in-IPv6 packet from the concentrator, the initiator decapsulates the
IPv6 packet to get the IPv4 packet with public destination IPv4
address. Then it performs NAT44 function and translates the
destination address into private one.
For host initiator case, it is suggested that the host runs a local
NAT to map randomly generated ports into the restricted, valid port
range. Private-public address translation would not be needed in
this NAT. Another solution is to have the IP stack to only assign
ports within the restricted, vailid range to applications. Either
way makes sure that every port number in the packets sent out by
itself falls into the allocated port range.
Sun, et al. Expires March 28, 2012 [Page 13]
Internet-Draft stateless 4over6 September 2011
8. Stateless 4over6 Concentrator Behavior
The stateless 4over6 concentrator should record the full set of sub-
domain rules. They can also be configured in a variety of methods,
and they can be refreshed or deleted once there is an adjustment on
address planning (no Initiator needs to be informed with this
adjustment).
The data plane functions of the concentrator is purely encapsulation
and de-capsulation. When receiving an IPv4-in-IPv6 packet from an
initiator, the concentrator de-capsulates it and forwards it to IPv4
Internet. When receiving an IPv4 packet from the Internet, it uses
the destination address and port from this packet to lookup the sub-
domain rules and calculate the specific "user-id" with port mapping
algorithm. Then the concentrator encapsulates this packet and
forwards it to the correct initiator based on native IPv6 routing.
The source address of IPv6 packet is just the concentrator address.
Sun, et al. Expires March 28, 2012 [Page 14]
Internet-Draft stateless 4over6 September 2011
9. CPE-CPE optimization
In order to support CPE-CPE optimization, it will delegate the full
sub-domain rules to BRAS device in the 4over6 domain. When the IPv4
destination of an IPv4-in-IPv6 packet is in the 4over6 domain, BRAS
performs IPv6 destination address translation, according to sub-
domain rules from the set, and the IPv4 destination address + port in
the packet. After the translation, the IPv6 packet can be forwarded
to the destination CPE directly without going through the
concentrator. However, this functionality is not a must in cast the
network is flat and there is no direct link between different CPEs.
Sun, et al. Expires March 28, 2012 [Page 15]
Internet-Draft stateless 4over6 September 2011
10. Mechanism Analysis
Stateless 4over6 does not need to inform multiple prefix mapping
rules to CPEs directly. Thus, there is no need to introduce dynamic
protocol for distributing and maintaining 4rd rules. This will turn
CPE to be a much simpler/dummier client, which will also
significantly reduce the burden of CPE management and trouble
shooting.
Besides, stateless 4over6 would be easier for address planning. SPs
only need to pre-determine the mapping relationship between IPv4
prefix and IPv6 prefix. Only concentrators( and BRAS in CPE-CPE
optimization case) need to be informed when changing a mapping rule.
And it fits well for scattered IPv4 address blocks. Moreover,
incremental CPE-CPE optimization can be achieved when network
providers would like to adjust their traffic when necessary.
The costs of stateless 4over6 for achieving the above benefits are
less optimized traffic by default. All traffic will be tunneled to
the concentrator when there is no prefix mapping BNGs. This is still
acceptable in flat network and few direct physical links between
different BNGs. However, if the network architecture is not flat and
concentrator is in the upper level of the network, it is recommended
that CPE-CPE optimization should be introduced.
Sun, et al. Expires March 28, 2012 [Page 16]
Internet-Draft stateless 4over6 September 2011
11. Security Considerations
See security considerations presented in [RFC6052] and [RFC6145].
Sun, et al. Expires March 28, 2012 [Page 17]
Internet-Draft stateless 4over6 September 2011
12. References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
[I-D.bsd-softwire-stateless-port-index-analysis]
Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port
Indexing Algorithms",
draft-bsd-softwire-stateless-port-index-analysis-00 (work
in progress), September 2011.
[I-D.cui-softwire-dhcp-over-tunnel]
Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP
tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work in
progress), July 2011.
[I-D.cui-softwire-host-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-cui-softwire-host-4over6-06 (work in progress),
July 2011.
[I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-ietf-softwire-stateless-4v6-motivation-00 (work in
progress), September 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.sun-v6ops-laft6]
Sun, Q. and C. Xie, "LAFT6: Lightweight address family
transition for IPv6", draft-sun-v6ops-laft6-01 (work in
progress), March 2011.
[I-D.tsou-pcp-natcoord]
Zhou, C., ZOU), T., Deng, X., Boucadair, M., and Q. Sun,
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-03 (work in
progress), July 2011.
Sun, et al. Expires March 28, 2012 [Page 18]
Internet-Draft stateless 4over6 September 2011
[I-D.xli-behave-divi-pd]
Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun,
"dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
Delegation", draft-xli-behave-divi-pd-01 (work in
progress), September 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
Sun, et al. Expires March 28, 2012 [Page 19]
Internet-Draft stateless 4over6 September 2011
Authors' Addresses
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552116>
Email: xiechf@ctbri.com.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785983
Email: jianping@cernet.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Sun, et al. Expires March 28, 2012 [Page 20]
Internet-Draft stateless 4over6 September 2011
Phone: +86-10-62785822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Cathy Zhou
Huawei Technologies
Section B, Huawei Industrial Base, Bantian Longgang
Shenzhen 518129
P.R.China
Phone: +86-10-58552116>
Email: cathyzhou@huawei.com
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Sun, et al. Expires March 28, 2012 [Page 21]
