One document matched: draft-wu-softwire-4over6-02.txt
Differences from draft-wu-softwire-4over6-01.txt
Network Working Group J. Wu
Internet-Draft Y. Cui
Intended status: Experimental X. Li
Expires: October 16, 2009 M. Xu
Tsinghua University
C. Metz
Cisco Systems, Inc.
April 14, 2009
4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions
draft-wu-softwire-4over6-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 16, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Wu, et al. Expires October 16, 2009 [Page 1]
Internet-Draft 4over6 April 2009
Abstract
The emerging and growing deployment of IPv6 networks, in particular
IPv6 backbone networks, will introduce cases where connectivity with
IPv4 networks is desired. In one such case, an Internet Service
Provider (ISP) operating an IPv6 backbone network will accomodate
connectivity and offer transit services for attached legacy IPv4
networks and applications. This is accomplished through the use of
IPv4-over-IPv6 (4over6) tunnels established between dual-stack IPv4/
IPv6 edge routers. Along with the growth of IPv6 backbones networks
and the corresponding increase in the number of attached IPv4
networks, the complexity of the interconnection tunnel topology will
severely increase to support the IPv4 transit service across the
backbone. The manual configuration mechanism for a potentially large
number of IPv4-over-IPv6 tunnels will cause an insufferable
operational burden. This document addresses this problem and
presents a mechanism for the automatic discovery and creation of
4over6 tunnels employing multi-protocol BGP extensions. The
mechanisms described in this document have been implemented, tested
and deployed on the CNGI-CERNET2 IPv6 testbed.
Wu, et al. Expires October 16, 2009 [Page 2]
Internet-Draft 4over6 April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. 4over6 Framework Overview . . . . . . . . . . . . . . . . . . 5
3. Prototype Implementation . . . . . . . . . . . . . . . . . . . 7
3.1. 4over6 Packet Forwarding . . . . . . . . . . . . . . . . . 7
3.2. Encapsulation table . . . . . . . . . . . . . . . . . . . 8
3.3. MP-BGP 4over6 Protocol Extensions . . . . . . . . . . . . 9
3.3.1. Receiving Routing Information from Local CE . . . . . 10
3.3.2. Receiving 4over6 Routing Information from a remote
4over6 PE . . . . . . . . . . . . . . . . . . . . . . 10
4. 4over6 Deployment Experience . . . . . . . . . . . . . . . . . 12
4.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network . . . . . 12
4.3. Deployment Experiences . . . . . . . . . . . . . . . . . . 13
5. Relationship to Softwires Mesh Effort . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Wu, et al. Expires October 16, 2009 [Page 3]
Internet-Draft 4over6 April 2009
1. Introduction
Due to the lack of IPv4 address space, more and more IPv6 networks
have been deployed not only on edge networks, but also on backbone
networks. However, there are still a large number of legacy IPv4
hosts and applications in the coming years. The emerging and growing
deployment of IPv6 networks, in particular IPv6 backbone networks,
will introduce cases where connectivity with IPv4 networks is
desired. Some IPv6 backbones will need to offer transit services to
attached IPv4 access networks. The ideal method to achieve this
would be to encapsulate and then transport the IPv4 payloads inside
IPv6 tunnels spanning the backbone. There are some IPv6/IPv4-related
tunneling protocols and mechanisms defined in the literature, but
most of these existing techniques focus on the problem of IPv6 over
IPv4, rather than the case of IPv4 over IPv6. Encapsulation methods,
(e.g. [RFC2473]) specified for generic packet tunneling in IPv6 do
exist and has been implemented. However they do not offer an easy
means to provision such tunnels which can place a manual
configuration burden on the operator, in particular if the number of
required tunnels grows large. Thus, new techniques are needed to
automatically create tunnels across an IPv6 backbone network
containing IPv4 payloads. The mechanisms defined in this document
are referred to as 4over6.
The 4over6 mechanism concerns two aspects: the control plane and the
data plane. The control plane needs to address the problem of how to
setup an IPv4 over IPv6 tunnel in an automatic and scalable fashion
between a large number of edge routers. This document defines
extensions to MP-BGP employed to communicate tunnel end-point
information and establish 4over6 tunnels between dual-stack Provider
Edge (PE) routers positioned at the edge of the IPv6 backbone
network. Once the 4over6 tunnel is in place, the data plane focuses
on the packet forwarding processes of encapsulation and
decapsulation.
Wu, et al. Expires October 16, 2009 [Page 4]
Internet-Draft 4over6 April 2009
2. 4over6 Framework Overview
In the topology shown in figure 1, a number of IPv6-only P routers
compose a native IPv6 backbone. The PE routers are dual-stack and
referred to as 4over6 PE routers. The IPv6 backbone acts as a
transit core to transport IPv4 packets across the IPv6 backbone.
This enables each of IPv4 access islands to communicate with each
other via 4over6 tunnels spanning the IPv6 transit core.
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| |
| |
__+____________________+__
4over6 / : : : : \ IPv6 only
Tunnels | : : : : | transit core
between | : [P] : | with multiple
PEs | : : : : | [P routers]
| : : : : |
\_._._._._._._._._._._._._./
| / \ |
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| | |
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
Figure 1: IPv4 over IPv6 network topology
As shown in figure 1, there are multiple dual-stack PE routers
connected to the IPv6 transit core. In order for the ingress 4over6
PE router to forward an IPv4 packet across the IPv6 backbone to the
correct egress 4over6 PE router, the ingress 4over6 PE router must
learn which IPv4 destination prefixes are reachable through each
egress 4over6 PE router. MP-BGP will be extended to distribute the
destination IPv4 prefix information between peering dual-stack PE
routers. Section 4 of this document presents the definition of the
4over6 protocol field in MP-BGP and section 5 describes MP-BGP's
Wu, et al. Expires October 16, 2009 [Page 5]
Internet-Draft 4over6 April 2009
extended behavior in support of this capability.
After the ingress 4over6 PE router learns the correct egress 4over6
PE router via MP-BGP, it will forward the packet across the IPv6
backbone using IP encapsulation. The egress 4over6 PE router will
receive the encapsulated packet, remove the IPv6 header and then
forward the original IPv4 packet to its final IPv4 destination.
Section 6 describes the procedure of packet forwarding.
Wu, et al. Expires October 16, 2009 [Page 6]
Internet-Draft 4over6 April 2009
3. Prototype Implementation
An implementatoin of the 4over6 mechanisms described in this document
was developed, tested and deployed on Linux with kernel version 2.4.
The prototype system is composed of three components: packet
forwarding, the encapsulation table and MP-BGP extensions. The
packet forwarding and encapsulation table are Linux kernel modules
and the MP-BGP extension was developed by extending Zebra routing
software.
The following sections will discuss these parts in detail.
3.1. 4over6 Packet Forwarding
Forwarding an IPv4 packet through the IPv6 transit core includes 3
parts: encapsulation of the incoming IPv4 packet with the IPv6 tunnel
header; transmission of the encapsulated packet over the IPv6 transit
backbone; and decapsulation of the IPv6 header and forwarding of the
original IPv4 packet. Native IPv6 routing and forwarding are
employed in the backbone network since the P routers take the 4over6
tunneled packets as just native IPv6 packets. Therefore, 4over6
packet forwarding involves only the encapsulation process and the
decapsulation process, both of which are peformed on the 4over6 PE
routers.
Tunnel from Ingress PE to Egress PE
---------------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+
|S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D|
+-+ +--+ +--+ +-+
Original Ingress PE Egress PE Original
Packet (Encapsulation) (Decapsulation) Packet
Source Destination
Node Node
Figure 2: Packet forwarding along 4over6 Tunnel
As shown in Figure 2, packet encapsulation and decapsulaion are both
on the dual-stack 4over6 PE routers. Figure 3 shows the format of
packet encapsulation and decapsulation.
Wu, et al. Expires October 16, 2009 [Page 7]
Internet-Draft 4over6 April 2009
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
|
|(Encapsulation on ingress PE)
|
v
< Tunnel IPv6 Headers > < Original IPv4 Packet >
+-----------+ - - - - - +-------------+-----------//--------------+
| IPv6 | IPv6 | IPv4 | |
| | Extension | | Packet Payload |
| Header | Headers | Header | |
+-----------+ - - - - - +-------------+-----------//--------------+
< Tunnel IPv6 Packet >
|
|(Decapsulation on egress PE)
|
v
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
Figure 3: Packet encapsulation and decapsulation on dual-stack 4over6
PE router
The encapsulation format to apply is IPv4 encapsulated in IPv6 as
outlined in [RFC2473].
3.2. Encapsulation table
Each 4over6 PE router maintains an encapsulation table as depicted in
Figure 4. Each entry in the encapsulation table consists of an IPv4
prefix and its corresponding IPv6 address. The IPv4 prefix is a
particular network located in an IPv4 access island network. The
IPv6 address is the 4over6 virtual interface (VIF) address of the
4over6 PE router that the IPv4 prefix is reachable through. The
encapsulation table is built and maintained using local configuration
information and MP-BGP advertisements received from remote 4over6 PE
routers.
The 4over6 VIF is an IPv6 /128 address that is locally configured on
each 4over6 router. This address, as an ordinary global IPv6
address, must also be injected into the IPv6 IGP so that it is
reachable across the IPv6 backbone.
Wu, et al. Expires October 16, 2009 [Page 8]
Internet-Draft 4over6 April 2009
+-------------+------------------------+
| IPv4 Prefix | IPv6 Advertising AFBR |
+-------------+------------------------+
Figure 4: Encapsulation Table
When an IPv4 packet arrives at the ingress 4over6 PE router, a lookup
in the local IPv4 routing table will result in a pointer to the local
encapsulation table entry with the matching destination IPv4 prefix.
There is a corresponding IPv6 address in the encapsulation table.
The IPv4 packet is encapsulated in an IPv6 header. The source
address in the IPv6 header is the IPv6 VIF address of the local
4over6 PE router and the destination address is the IPv6 VIF address
of the remote 4over6 PE router contained in the local encapsulation
table. The packet is then subjected to normal IPv6 forwarding for
transport across the IPv6 backbone.
When the encapsulated packet arrives at the egress 4over6 PE router,
the IPv6 header is removed and the original IPv4 packet is forwarded
to the destination IPv4 network based on the outcome of the lookup in
the IPv4 routing table contained in the egress 4over6 PE router.
3.3. MP-BGP 4over6 Protocol Extensions
Each 4over6 PE router possesses an IPv4 interface connected to an
IPv4 access network(s). It can peer with other IPv4 routers using
IGP or BGP routing protocols to exchange local IPv4 routing
information. Routing information can also be installed on the 4over6
PE router using static configuration methods.
Each 4over6 PE also possesses at least one IPv6 interface to connect
it into the IPv6 transit backbone. The 4over6 PE typically uses IGP
routing protocols to exchange IPv6 backbone routing information with
other IPv6 P routers. The 4over6 PE router will also form an MP-iBGP
peering relationship with other 4over6 PE routers connected to the
IPv6 backbone network.
The use of MP-iBGP suggests that the participating 4over6 PE routers
that share a route reflector or form a full mesh of TCP connections
are contained in the same autonomous system (AS). This
implementation is in fact only deployed over a single AS. This was
not an intentional design constraint but rather reflected the single
AS topology of the CNGI-CERNET2 national IPv6 backbone used in the
testing and deployment of this solution.
Wu, et al. Expires October 16, 2009 [Page 9]
Internet-Draft 4over6 April 2009
3.3.1. Receiving Routing Information from Local CE
When a 4over6 PE router learns routing information from the locally
attached IPv4 access networks, the 4over6 MP-iBGP entity should
process the information as follows:
1. Install and maintain local IPv4 routing information in the IPv4
routing database.
2. Install and maintain new entries in encapsulation table. Each
entry should consist of the IPv4 prefix and the local IPv6 VIF
address.
3. Advertise the new contents of the local encapsulation table in
the form of MP_REACH_NLRI update information to remote 4over6 PE
routers. The format of these updates is as follows:
* AFI = 1 (IPv4)
* SAFI = 67 (4OVER6)
* NLRI = IPv4 network prefix
* Network Address of Next Hop = IPv6 address of its 4over6 VIF
4. A new SAFI for this solution was obtained as SAFI_4OVER6 (67)
from IANA. We call BGP update with SAFI being 67 as 4over6
routing information.
3.3.2. Receiving 4over6 Routing Information from a remote 4over6 PE
A local 4over6 PE router will receive MP_REACH_NLRI updates from
remote 4over6 routers and use that information to populate the local
encapsulation table and the BGP routing database. After validating
correctness of the received attribute, the following procedures are
used to update the local encapsulation table and redistribute to
local IPv4 routing table:
1. Validate the received BGP update packet as 4over6 routing
information by AFI = 1 (IPv4) and SAFI = 67 (4OVER6)
2. Extract the IPv4 network address from the NLRI field and install
as the IPv4 network prefix
3. Extract the IPv6 address from the Network Address of the Next Hop
field and place that as an associated entry next to the IPv4
network index. (Note this describes the update of local encap
table.)
Wu, et al. Expires October 16, 2009 [Page 10]
Internet-Draft 4over6 April 2009
4. Install and maintain a new entry in encapsulation table with the
extracted IPv4 prefix and its corresponding IPv6 address.
5. Redistribute the new 4over6 routing information to local IPv4
routing table. Set the destination network prefix as the
extracted IPv4 prefix, set the Next Hop as Null, and Set the
OUTPUT Interface as the 4over6 VIF on the local 4over6 PE router.
Therefore, when an ingress 4over6 PE router receives an IPv4 packet,
the lookup in its IPv4 routing table will have a result of the output
interface as the local 4over6 VIF, where the incoming IPv4 packet
will be encapsulated with a new IPv6 header as indicated in the
encapsulation table.
Wu, et al. Expires October 16, 2009 [Page 11]
Internet-Draft 4over6 April 2009
4. 4over6 Deployment Experience
4.1. CNGI-CERNET2
A prototype of the 4over6 solution is implemented and deployed on
CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation
Internet (CNGI) backbones, operated by the China Education and
Research Network (CERNET). CNGI-CERNET2 connects approximately 25
core nodes distributed in 20 cities in China at speeds of 2.5-10
Gb/s. The CNGI-CERNET2 backbone is IPv6-only with some attached
customer premise networks (CPN) being dual-stack. The CNGI-CERNET2
backbone, attached CNGI-CERNET2 CPNs, and CNGI-6IX Exchange all have
globally unique AS numbers. This IPv6 backbone is used to provide
transit IPv4 services for customer IPv4 networks connected via 4over6
PE routers to the backbone.
4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network
Figure 5 shows 4over6 deployment network topology.
+-----------------------------------------------------+
| IPv6 (CERNET2) |
| |
+-----------------------------------------------------+
| | | |
Tsinghua|Univ. Peking|Univ. SJTU| Southeast|Univ.
+------+ +------+ +------+ +------+
|4over6| ... |4over6| |4over6| ... |4over6|
|router| |router| |router| |router|
+------+ +------+ +------+ +------+
| | | |
| | | |
| | | |
+-----------+ +-----------+ +-----------+ +-----------+
|IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access|
| network | | network | | network | | network |
+-----------+ +-----------+ +-----------+ +-----------+
|
+----------------------+
| IPv4 (Internet) |
| |
+----------------------+
Figure 5: 4over6 deployment network topology
The IPv4-only access networks are equipped with servers and clients
Wu, et al. Expires October 16, 2009 [Page 12]
Internet-Draft 4over6 April 2009
running different applications. The 4over6 PE routers are deployed
at 8 x IPv6 nodes of CNGI-CERNET2, located in 7 universities and 5
cities across China. As suggested in figure 5 some of the IPv4
access networks are connected to both IPv6 and IPv4 networks and
others are only connected to the IPv6 backbone. In the deployment,
users in different IPv4 networks can communicate with each other
through 4over6 tunnels.
4.3. Deployment Experiences
A number of 4over6 PE routers were deployed and configured to support
the 4over6 transit solution. MP-BGP peerings were established, and
successful distribution of 4over6 SAFI information occured.
Inspection of the BGP routing and encapsulation tables confirmed that
the correct entries were sent and received. ICMP ping traffic
indicated that IPv4 packets were successfully transiting the IPv6
backbone.
In addition other application protocols were successfully tested per
the following:
o HTTP. A client running Internet Explorer in one IPv4 client
network was able to access and download multiple objects from an
HTTP server located in another IPv4 client network.
o P2P. BitComet software running on several PCs placed in different
IPv4 client networks were able to find each other and share files.
Other protocols, including FTP, SSH, IM(MSN, GTalk) and Multimedia
Streaming, all functioned correctly.
Wu, et al. Expires October 16, 2009 [Page 13]
Internet-Draft 4over6 April 2009
5. Relationship to Softwires Mesh Effort
The 4over6 solution was presented at the IETF Softwires Working Group
Interim meeting in Honk Kong in January 2006. The existence of this
large-scale implementation and deployment clearly showed that MP-BGP
could be employed to support tunnel setup in a scalable fashion
across an IPv6 backbone. Perhaps most important was the use-case
presented, that being an IPv6 backbone offering transit to attached
client IPv4 networks.
The 4over6 solution can be viewed as a precursor to softwires mesh
framework. However there are several differences with this solution
and the effort that emerged from the softwires working group called
softwires mesh framework[I-D.ietf-softwire-mesh-framework].
o MP-BGP Extensions. 4over6 employs a new SAFI (4OVER6) to convey
client IPv4 prefixes between 4over6 PE routers. Softwires Mesh
retains original AFI-SAFI designations but uses a modified
MP_REACH_NLRI format to convey IPv4 NLRI prefix information with
an IPv6 next_hop address[I-D.ietf-softwire-v4nlri-v6nh].
o Encapsulation. 4over6 assumes IP-in-IP or it is possible to
configure GRE. Softwires uses those two scenarios configured
locally or for IP headers that require dynamic updating. As a
result, the BGP encap safi is introduced in
Softwires[I-D.ietf-softwire-encaps-safi].
o Multicast. The basic 4over6 solution only implemented unicast
communications. The multicast communications is specified in the
Softwire Mesh Framework, and also supported by the multicast
extension of 4over6.
o Use-Cases. The 4over6 solution in this document specifies the
4over6 use-case, which is also pretty easy to extend for the use-
case of 6over4. The softwires mesh framework supports both 4over6
and 6over4.
Wu, et al. Expires October 16, 2009 [Page 14]
Internet-Draft 4over6 April 2009
6. IANA Considerations
A new SAFI value (67) was assigned by IANA for 4over6 BGP extension:
SAFI_4OVER6.
Wu, et al. Expires October 16, 2009 [Page 15]
Internet-Draft 4over6 April 2009
7. Security Considerations
Tunneling mechanisms, especially automatic ones, often have potential
problems of DDoS attacks on the tunnel-entry point or tunnel-end
point. However, since 4over6 BGP extension don't allocate resources
to each flow or maintain the state of each flow, the 4over6 PE
routers will have a capacity of enduring DDoS attacks as a common
router. I-BGP peering relationship may be maintained over IPSec or
other secure communications.
Wu, et al. Expires October 16, 2009 [Page 16]
Internet-Draft 4over6 April 2009
8. Conclusion
The emerging and growing deployment of IPv6 networks, in particular
IPv6 backbone networks, will introduce cases where connectivity with
IPv4 networks is desired. Some IPv6 backbones will need to offer
transit services to attached IPv4 access networks. The 4over6
solution outlined in this document supports such a capability through
an extension to MP-BGP to convey IPv4 routing information along with
an associated IPv6 address. Basic IP encapsulation is used in the
dataplane as IPv4 packets are tunneled through the IPv6 backbone.
An actual implemention has been developed and deployed on the CNGI-
CERNET2 IPv6 backbone.
Wu, et al. Expires October 16, 2009 [Page 17]
Internet-Draft 4over6 April 2009
9. Acknowledgements
During the design procedure of the 4over6 framework and definition of
BGP-MP 4over6 extension, Professor Ke Xu gave the authors many
valuable comments. The support of IETF softwire WG is also
gratefully acknowledged with special thanks to David Ward and Mark
Townsley for their rich experience and knowledge in this field. Many
thanks to Yakov Rekhter for his helpful comments and advice.
The deployment and test for the prototype system was conducted among
7 universities -- namely, Tsinghua University, Peking University,
Beijing University of Post and Telecommunications, Shanghai Jiaotong
University, Huazhong University of Science and Technology, Southeast
University, South China University of Technology. The authors would
like to thank everyone involved in this effort in these universities.
Wu, et al. Expires October 16, 2009 [Page 18]
Internet-Draft 4over6 April 2009
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 2842, May 2000.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
10.2. Informative References
[I-D.ietf-idr-rfc2858bis]
Bates, T., "Multiprotocol Extensions for BGP-4",
draft-ietf-idr-rfc2858bis-10 (work in progress),
March 2006.
[I-D.ietf-softwire-encaps-safi]
Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
BGP Tunnel Encapsulation Attribute",
draft-ietf-softwire-encaps-safi-05 (work in progress),
February 2009.
[I-D.ietf-softwire-mesh-framework]
Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", draft-ietf-softwire-mesh-framework-06 (work in
progress), February 2009.
[I-D.ietf-softwire-problem-statement]
Dawkins, S., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-03 (work in
progress), March 2007.
Wu, et al. Expires October 16, 2009 [Page 19]
Internet-Draft 4over6 April 2009
[I-D.ietf-softwire-v4nlri-v6nh]
Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer
Reachability Information with an IPv6 Next Hop",
draft-ietf-softwire-v4nlri-v6nh-02 (work in progress),
January 2009.
[I-D.wu-softwire-4over6]
Wu, J., "4over6 Transit using Encapsulation and BGP-MP
Extension", draft-wu-softwire-4over6-01 (work in
progress), September 2006.
Wu, et al. Expires October 16, 2009 [Page 20]
Internet-Draft 4over6 April 2009
Authors' Addresses
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
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: cy@csnet1.cs.tsinghua.edu.cn
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: xmw@csnet1.cs.tsinghua.edu.cn
Wu, et al. Expires October 16, 2009 [Page 21]
Internet-Draft 4over6 April 2009
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: chmetz@cisco.com
Wu, et al. Expires October 16, 2009 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 14:59:17 |