One document matched: draft-cui-softwire-host-4over6-03.txt
Differences from draft-cui-softwire-host-4over6-02.txt
Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track P. Wu
Expires: June 3, 2011 Tsinghua University
C. Metz
Cisco Systems, Inc.
O. Vautrin
Juniper Networks
Y. Lee
Comcast
November 30, 2010
4over6 Access for IPv4 provisioning in IPv6 network
draft-cui-softwire-host-4over6-03
Abstract
This draft proposes a mechanism for bidirectional IPv4 communication
between IPv4 Internet and end hosts or IPv4 networks sited in IPv6
access networks. This mechanism follows the softwire hub & spoke
model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6
network. By allocating public IPv4 addresses to end hosts/networks
in IPv6, it can achieve IPv4 end-to-end bidirectional communication
between IPv4 Internet and these hosts/networks. This mechanism is an
IPv4 access method for hosts and IPv4 networks sited in IPv6.
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 June 3, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cui, et al. Expires June 3, 2011 [Page 1]
Internet-Draft 4over6 Access November 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Cui, et al. Expires June 3, 2011 [Page 2]
Internet-Draft 4over6 Access November 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment scenario . . . . . . . . . . . . . . . . . . . . . 7
4.1. Scenario description . . . . . . . . . . . . . . . . . . . 7
4.2. Communication requirements . . . . . . . . . . . . . . . . 7
5. 4over6 Access Mechanism . . . . . . . . . . . . . . . . . . . 9
5.1. Address allocation . . . . . . . . . . . . . . . . . . . . 9
5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 9
5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 10
5.4. IPv4-IPv6 mapping maintaining methods . . . . . . . . . . 12
6. Combination with Dual-stack Lite . . . . . . . . . . . . . . . 13
6.1. Combination of 4over6 initiator and B4 . . . . . . . . . . 13
6.2. Combination in the DHCPv6 server . . . . . . . . . . . . . 13
6.3. Combination of 4over6 concentrator and AFTR . . . . . . . 13
7. Technical advantages . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Cui, et al. Expires June 3, 2011 [Page 3]
Internet-Draft 4over6 Access November 2010
1. Introduction
Global IPv4 addresses are running out fast. Meanwhile, the demand
for IP address is still growing and may even burst in potential
circumstances like the "Internet of Things". To satisfy the end
users, operators have to push IPv6 to the front, by building IPv6
networks and providing IPv6 services.
When IPv6-only network are widely deployed, users of those networks
will probably still need IPv4 connectivity. This is because part of
Internet will stay IPv4-only for a long time, and network users in
IPv6-only network will communicate with network users sited in the
IPv4-only part of Internet. This need could eventually decrease with
the general IPv6 adoption.
Network operators should provide IPv4 services to IPv6 users to
satisfy their needs, usually through tunnels. This type of IPv4
services differ by provisioned IPv4 addresses. If the users can't
get public IPv4 addresses (e.g., new network users join an ISP which
don't have enough unused IPv4 addresses), they have to use private
IPv4 addresses on the client side, and IPv4-private-to-public
translation is required on the carrier side, as is described in Dual-
stack Lite[I-D.ietf-softwire-dual-stack-lite]. Otherwise the users
can get public IPv4 addresses, and use them for IPv4 communication.
In this case, translation shouldn't be involved. Then the network
users and operators can avoid all the problems caused by translation,
such as ALG, NAT traversal, state maintenance, etc. Note that this
"public IPv4" situation is actually quite common. There're nearly
2^32 network users who are using or can potentially get public IPv4
addresses. Most of them will switch to IPv6 sooner or later, and
will require IPv4 services for a significant period after the
switching. This draft focuses on this situation, i.e., to provide
IPv4 access for users in IPv6 networks, where IPv4 public addresses
are still available.
Cui, et al. Expires June 3, 2011 [Page 4]
Internet-Draft 4over6 Access November 2010
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].
Cui, et al. Expires June 3, 2011 [Page 5]
Internet-Draft 4over6 Access November 2010
3. Terminology
4over6 Access: 4over6 Access is the mechanism proposed by this draft.
Generally, 4over6 Access supports bidirectional communication between
IPv4 Internet and IPv4 hosts or local networks in IPv6 access
network, by leveraging IPv4-in-IPv6 tunnel and public IPv4 address
allocation.
4over6 initiator: in 4over6 Access mechanism, 4over6 initiator is the
IPv4-in-IPv6 tunnel initiator located on the user side of IPv6
network. The 4over6 initiator can be either a dual-stack capable
host or a dual-stack CPE device. In the former case, the host has
both IPv4 and IPv6 stack but is provisioned with IPv6 access only.
In the latter case, the CPE has both IPv6 interface for access to ISP
network and IPv4 interface for local network connection; hosts in the
local network can be IPv4-only.
4over6 concentrator: in 4over6 Access mechanism, 4over6 concentrator
is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network.
It's a dual-stack router which connects to both the IPv6 network and
IPv4 Internet.
Cui, et al. Expires June 3, 2011 [Page 6]
Internet-Draft 4over6 Access November 2010
4. Deployment scenario
4.1. Scenario description
The general scenario of 4over6 Access is shown in Figure 1. Users in
an IPv6 network take IPv6 as their native service. Some users are
end hosts which face the ISP network directly, while others are local
networks behind CPEs, such as a home LAN, an enterprise network, etc.
The ISP network is IPv6-only rather than dual-stack, which means that
ISP can't provide native IPv4 access to its users; however, it's
acceptable that one or more routers on the carrier side become dual-
stack and get connected to IPv4 Internet. So if network users want
to connect to IPv4, these dual-stack routers will be their
"entrances".
+-------------------------+
| IPv6 ISP Network |
+------+ |
|host: | |
|initi-| |
|ator |=================+-------+ +-----------+
+------+ |4over6 | | IPv4 |
| IPv4-in-IPv6 |Concen-|---| Internet |
+----------+ +------+ |trator | | |
|local IPv4|--|CPE: |=================+-------+ +-----------+
| network | |initi-| |
+----------+ |ator | |
+------+ |
| |
+-------------------------+
Figure 1 4over6 Access scenario
4.2. Communication requirements
Before getting into any technical details, the communication
requirements should be stated. The first one is that, 4over6 users
require IPv4-to-IPv4 communication with the IPv4 Internet. An IPv4
access service is needed rather than an IPv6-to-IPv4 translation
service. (IPv6-to-IPv4 communication is out of the scope of this
draft.)
Second, 4over6 users require public IPv4 addresses rather than
private addresses. Public IPv4 address means there's no IPv4 CGN
along the path, so the acquired IPv4 service is btter. In
particular, some hosts may be application servers, public address
Cui, et al. Expires June 3, 2011 [Page 7]
Internet-Draft 4over6 Access November 2010
works btter for reasons like straightforward access, direct DNS
registration, no stateful mapping maintainence on CGN, etc. We
assume the IPv4 public addresses are available, which is quite common
as we covered in section 1.
Third, translation is not preferred in this scenario. If this IPv4-
to-IPv4 communication is achieved by translation, it'll needs double
translation along the path, one from IPv4 to IPv6 and the other from
IPv6 back to IPv4. It's quite complicated. Contrarily a tunnel can
achieve the IPv4-over-IPv6 traversing easily. That's the reason this
draft follows the hub & spoke softwire model.
Cui, et al. Expires June 3, 2011 [Page 8]
Internet-Draft 4over6 Access November 2010
5. 4over6 Access Mechanism
5.1. Address allocation
4over6 Access can be generally considered as IPv4-over-IPv6 hub &
spoke tunnel using public IPv4 address. Each 4over6 initiator will
use a unique, public IPv4 address for IPv4-over-IPv6 communication.
This means one IPv4 address for one host in host initiator case and
one IPv4 address for one local IPv4 network in CPE initiator case.
In the latter case, the CPE can then operate a local IPv4 NAT to
share the IPv4 address between hosts in the local network. Note that
local NAT is much more controllable and configurable than CGN. If
the hosts in the local network need dedicated IPv4 addresses, just
extend IPv6 across the CPE and make the local network IPv6. This way
every host can be a dedicated 4over6 initiator.
The key problem here is IPv4 address allocation over IPv6 network,
from ISP device(s) to separated 4over6 initiators. Native IPv4
address allocation is done either in a dynamic way through DHCPv4, or
in a static way through manual configuration. 4over6 Access should
support both. DHCPv4 over IPv6 can be achieved through IPv4-in-IPv6
tunnel between ISP device and 4over6 initiators. As to manual
configuration, 4over6 users and the ISP operators should negotiate
beforehand to authorize the IPv4 address.
Along with this address allocation, the concentrator needs to
maintain the address mappings between the IPv4 address and IPv6
address of 4over6 initiators. This is required to provide correct
destination address for encapsulation. There are several ways to
achieve this mapping maintaining: DHCPv4-driven updating, traffic
snooping and manual configuration. This draft recommends the first
way for dynamic maintaining and describe it in detail, and then
compare it with traffic snooping in section 5.4.
5.2. 4over6 initiator behavior
4over6 initiator has an IPv6 interface connected to the IPv6 ISP
network, and a tunnel interface to support IPv4-in-IPv6
encapsulation. In CPE case, it has at least one IPv4 interface
connected to IPv4 local network.
4over6 initiator should learn the 4over6 concentrator's IPv6 address
beforehand. For example, if the initiator gets its IPv6 address by
DHCPv6, it should get the 4over6 concentrator's IPv6 address through
a DHCPv6 option[I-D.ietf-softwire-ds-lite-tunnel-option].
Usually, 4over6 initiator gets the public IPv4 address by DHCPv4 on
an IPv4-in-IPv6 tunnel. A standard DHCPv4 client in the initiator
Cui, et al. Expires June 3, 2011 [Page 9]
Internet-Draft 4over6 Access November 2010
will run on the tunnel interface to acquire IPv4 address. All the
DHCPv4 packets generated by the client will be encapsulated and
forwarded to the 4over6 concentrator, and all the DHCPv4 replies from
the concentrator encapsulating in IPv6 will be decapsulated by the
tunnel interface and handed to the client. This way the DHCP client
can get a dynamic public IPv4 address from the concentrator, and
assign it to the tunnel interface.
If the address allocation is static, 4over6 user should negotiate
with the ISP operator beforehand. The user needs to learn the IPv4
address provisioned by the operator, and inform the operator the IPv6
address of the initiator, to install the address mapping on the
concentrator.
For IPv4 traffic, 4over6 initiator performs the IPv4-in-IPv6
encapsulation and decapsulation on the tunnel interface, which has
its IPv4 address already assigned. When processing an IPv4 packet
destinated to the IPv4 Internet(either generated by the initiator
itself, or received from the local network and translated by local
NAT44), it performs the encapsulation, using the IPv6 address of the
4over6 concentrator as the IPv6 destination address, and the IPv6
address of itself as the IPv6 source address. The encapsulated
packet will be forwarded to the IPv6 network. The decapsulation on
4over6 initiator is simple. When receiving an IPv4-in-IPv6 packet,
the initiator just drops the IPv6 header, and either hands it to
upper layer, or performs the local NAT44 translation and then
forwards it to the IPv4 local network.
5.3. 4over6 concentrator behavior
4over6 concentrator represents the IPv4-IPv6 border router working as
tunnel endpoint for 4over6 initiators, with its IPv6 interface
connected to the IPv6 network, IPv4 interface connected to the IPv4
Internet, and a tunnel interface supporting IPv4-in-IPv6
encapsulation and decapsulation. 4over6 concentrator maintains an
IPv4-IPv6 address mapping table for IPv4 data packet encapsulation.
4over6 concentrator is responsible for DHCPv4 address allocation to
4over6 initiators. For static allocation, the concentrator just
install the IPv4-IPv6 address mapping into the mapping table after
negotiating with a 4over6 user. As to dynamic allocation, the
concentrator should either run a DHCPv4 server on the tunnel
interface to dynamically allocate public addresses to 4over6
initiators, or perform the DHCPv4 relay functions and leave the
actual address allocation job to a dedicated DHCPv4 server. In both
cases, when allocating an address, the concentrator should install an
entry of the allocated IPv4 address and the initiator's IPv6 address
into the address mapping table. This entry should be deleted when
Cui, et al. Expires June 3, 2011 [Page 10]
Internet-Draft 4over6 Access November 2010
receiving a DHCP release or reaching a lease expiration. All the
update should be triggered by the DHCP process(see Figure 2). Note
that in the DHCP relay case, the relay should be extended to maintain
the lifetime of address leases.
The DHCP packets the concentrator is performed in IPv4-in-IPv6
tunnel. The difficulty here is that before DHCP address allocation
is done, the initiator may not have an IPv4 address, and the
concentrator doesn't have an IPv4-IPv6 mapping for IPv6 encapsulation
of corresponding DHCP packets. So when the concentrator receives a
DHCP packet, it should store the mapping of IPv6 source address of
this packet and the MAC address in the DHCP payload temporarily.
This mapping will be used for encapsulation of outgoing DHCP packets.
The concentrator should use the MAC address in the payload of an
outing DHCP packet to match the correct IPv6 encapsulation
destination address.
DHCP EVENT initi- concen- BEHAVIOR
ator trator
allocating a new |---DHCPDISCOVER-->| store IPv6-MAC mapping
network address |<-----DHCPOFFER---|
|---DHCPREQUEST--->|
|<-----DHCPACK-----| install IPv4-IPv6 mapping
| : |
address renewal |---DHCPREQUEST--->| store IPv6-MAC mapping
|<-----DHCPACK-----| update lease lifetime
| : |
address release |---DHCPRELEASE--->| delete IPv4-IPv6 mapping
| : |
lease expiration | no message | delete IPv4-IPv6 mapping
Figure 2 4over6 concentrator: DHCP behavior
On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6
packets coming from 4over6 initiators. It removes the IPv6 header of
every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. On
the IPv4 side, the concentrator encapsulates the IPv4 packets
destined to 4over6 initiators. When performing the IPv4-in-IPv6
encapsulation, the concentrator uses its own IPv6 address as the IPv6
source address. As to IPv6 destination address, the concentrator
will look up the IPv4-IPv6 address mapping table, use the IPv4
destination address of the packet to find the correct IPv6 address.
After the encapsulation, the concentrator forwards the IPv6 packet on
its IPv6 interface to reach an initiator.
The 4over6 concentrator, or its upstream router should advertise the
IPv4 prefix which contains the addresses of 4over6 initiators on the
Cui, et al. Expires June 3, 2011 [Page 11]
Internet-Draft 4over6 Access November 2010
IPv4 side, to make these initiators reachable on IPv4 Internet.
Since the concentrator has to maintain the IPv4-IPv6 address mapping
table, the concentrator is stateful in IP level. Note that this
table will be much smaller than a CGN table, as there is no port
information involved.
5.4. IPv4-IPv6 mapping maintaining methods
section 5.3 describes the address mapping maintaining with DHCP-
driven updating, in which DHCP process on the concentrator triggers
installation and deletion of IPv4-IPv6 address mappings. Another way
to maintain the mapping is traffic snooping, i.e., record the address
mapping when decapsulating IPv4-in-IPv6 data packets coming from
4over6 initiators. In this way, the mappings are installed based on
the actual traffic rather than DHCP. However, the shortage of this
method is that extra procedure is required to support inbound access
well. This happens when there's no mapping exists on the
concentrator for an allocated IPv4 address, either because there's no
outbound traffic from this IP yet or because the earlier-installed
mapping has expired, while packets from the IPv4 Internet have
already arrived on the concentrator and tried to reach the
corresponding IP. To solve this problem, the 4over6 initiator need
to send keepalive "pinhole" packets to the concentrator. A pinhole
packet can be an arbitrary IPv4 packet which can reach the
concentrator. This draft recommends the DHCP-driven updating method
since it's more accurate and controllable, and requires no extra
procedure on the initiator.
If an operator chooses the DHCP-driven updating method, the
concentrator need manual mapping configuration as well for static
configured 4over6 initiators. The traffic snooping method works for
both static and dynamic 4over6 initiators, though.
Cui, et al. Expires June 3, 2011 [Page 12]
Internet-Draft 4over6 Access November 2010
6. Combination with Dual-stack Lite
The scenario will be common in which an operator do have some unused
IPv4 addresses, but not enough for every user. This requires a
combination of Dual-stack Lite and 4over6 Access to provide IPv4
access for all the users. 4over6 Access uses public IPv4 address
while Dual-stack Lite uses private IPv4 address, so ordinary users
can use Dual-stack Lite to get IPv4 access, and high-priority users
such as application servers can use 4over6 Access to get btter IPv4
access. 4over6 Access can easily collaborate with Dual-Stack Lite,
since the functions of 4over6 initiator are quite close to DS-lite
B4, and the functions of 4over6 concentrator are quite close to DS-
lite AFTR.
6.1. Combination of 4over6 initiator and B4
The initiator and B4 uses same IPv4-in-IPv6 encapsulation and
decapsulation method, so they can use one tunnel interface. The
initiator/B4 should support DS-lite as basic IPv4 access method, and
assign IPv4 private address to the tunnel interface. If it can get
public IPv4 address(and hence 4over6 Access), then this address
should be assigned to the tunnel interface as primary address, and
leave the private IPv4 address as sencondary address. In this way,
4over6 Access will be the preferred access method and DS-lite will be
the basic method.
6.2. Combination in the DHCPv6 server
DHCPv6 server need to allocate IPv6 addresses with the option
containing 4over6 concentrator/AFTR address, to 4over6 initiator/B4.
6.3. Combination of 4over6 concentrator and AFTR
4over6 Access and DS-lite can use the same concentrator/AFTR device.
They can use one tunnel interface for encapsulation and
decapsulation. The device will support NAT-related functions only
for DS-lite, and support DHCP function and IPv4-IPv6 mapping table
only 4over6 Access. The concentrator can distinguish between
outbound packets of Dual-stack Lite and 4over6 Access by the source
IPv4 address: if it is public, it is a 4over6 Access packet;
otherwise, it is a Dual-stack Lite packet. Besides, the concentrator
can distinguish inbound IPv4 packets based on IPv4 destination
address, as long as 4over6 Access and Dual-stack lite use different
public IPv4 address range.
In practical situation, the concentrator/AFTR should maintain a
4over6 authority list, which contains the IPv6 addresses of all the
authorized 4over6 subscribers(initiators). If a subscriber is on the
Cui, et al. Expires June 3, 2011 [Page 13]
Internet-Draft 4over6 Access November 2010
list, it can get a public IPv4 address and the 4over6 Access service.
Else it has to use private IPv4 address and DS-lite for IPv4
communication.
Cui, et al. Expires June 3, 2011 [Page 14]
Internet-Draft 4over6 Access November 2010
7. Technical advantages
4over6 Access provides a method for users in IPv6 network to
communicate with IPv4. In many scenarios, this can be viewed as an
alternative to IPv6-IPv4 translation mechanisms which have well-known
limitations described in [RFC4966] .
Since a 4over6 initiator uses a public IPv4 address, 4over6 Access
supports full bidirectional communication between IPv4 Internet and
hosts/networks in IPv6 access network. In particular, it supports
the servers in IPv6 network to provide IPv4 application service
transparently.
4over6 Access supports dynamic reuse of a single IPv4 address between
multiple subscribers based on their dynamic requirement of
communicating with IPv4 Internet. A subscriber will request a public
IPv4 address for a period of time only when it need to communicate
with IPv4 Internet. Besides, in the CPE case, one public IPv4
address will be shared by the local network. So 4over6 Access can
improve the reuse rate of IPv4 addresses.
4over6 Access is suited for network users/ISPs which can still get/
provide public IPv4 addresses. Dual-stack lite is suited for network
users/ISPs which can no longer get/provide public IPv4 addresses. By
combining 4over6 Access and Dual-stack lite, the IPv4-over-IPv6 Hub &
spoke problem can be well solved.
Cui, et al. Expires June 3, 2011 [Page 15]
Internet-Draft 4over6 Access November 2010
8. Acknowledgement
The authors would like to thank Alain Durand and Dan Wing for their
valuable comments on this draft.
Cui, et al. Expires June 3, 2011 [Page 16]
Internet-Draft 4over6 Access November 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
9.2. Informative References
[I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-06 (work in
progress), November 2010.
[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-06 (work
in progress), August 2010.
Cui, et al. Expires June 3, 2011 [Page 17]
Internet-Draft 4over6 Access November 2010
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
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-6278-5983
Email: jianping@cernet.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA 95134
USA
Email: chmetz@cisco.com
Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: Olivier@juniper.net
Cui, et al. Expires June 3, 2011 [Page 18]
Internet-Draft 4over6 Access November 2010
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
Cui, et al. Expires June 3, 2011 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 08:08:25 |