One document matched: draft-wu-softwire-4over6-01.txt
Differences from draft-wu-softwire-4over6-00.txt
Network Working Group J. Wu
Internet-Draft Y. Cui
Expires: March 13, 2007 X. Li
Tsinghua University
September 9, 2006
4over6 Transit using Encapsulation and BGP-MP Extension
draft-wu-softwire-4over6-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 March 13, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Due to the rapid deployment of IPv6 networks, especially IPv6
backbones, the existing long-live IPv4 networks are going to be
connected to these IPv6 networks. In the environment that ISP hopes
to use IPv6 backbones while still provides end users IPv4 access to
support existing IPv4 applications, IPv4 traffic needs to be
transported over IPv6 backbones. Along with the growth of IPv6
backbones, the number of IPv4 access networks increases and the
Wu, et al. Expires March 13, 2007 [Page 1]
Internet-Draft 4over6 September 2006
IPv4/v6 interconnection topology becomes complex. Therefore, the
existing manual configuration mechanism for a large number of end-2-
end tunnels will cause an insufferable burden. This draft addresses
this problem and presents a mechanism of automatic 4over6 tunnel-end
discovery with BGP extensions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 4over6-related terminology . . . . . . . . . . . . . . . . 4
3. Intra-domain 4over6 framework . . . . . . . . . . . . . . . 5
4. 4over6 packet forwarding . . . . . . . . . . . . . . . . . . 7
5. BGP-MP 4over6 protocol definition . . . . . . . . . . . . . 10
6. Behavior of BGP-MP 4over6 extension . . . . . . . . . . . . 11
6.1 Receiving routing information from CE . . . . . . . . . . 11
6.2 Receiving routing information from PE . . . . . . . . . . 12
7. 4over6 Error Processing . . . . . . . . . . . . . . . . . . 13
8. Implementation and deployment . . . . . . . . . . . . . . . 14
9. Extension to IPv6 over IPv4 . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . 17
12. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . 18
13. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1 Normative References . . . . . . . . . . . . . . . . . . 21
15.2 Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . 23
Wu, et al. Expires March 13, 2007 [Page 2]
Internet-Draft 4over6 September 2006
1. Introduction
With the rapid deployment of IPv6 networks, especially IPv6
backbones, some IPv6 backbones need to act as IPv6 transit cores to
provide packet transport service to IPv4 access networks. Although
there are some related tunneling protocols or mechanisms in the
literature, most of the existing tunneling mechanisms focus on the
problem of IPv6 over IPv4, rather than the upcoming one of IPv4 over
IPv6. Additionally, although some encapsulation methods, e.g.
[RFC2473], present specifications for generic packet tunneling in
IPv6, the insufferable burden of manual configuration prevents the
wide deployment of existing related end-2-end tunnels in a large-
scale IPv4/v6 interconnected networks. Thus, new techniques need to
provide automatic tunneling mechanism for scalable IPv4 packet
transmission over an IPv6 backbone, which is abbreviated as 4over6.
Generally speaking, 4over6 mechanism concerns two aspects: the
control plane and the data plane. The control plane needs to solve
the problem of how to setup an IPv4 over IPv6 tunnel with proper
method of tunnel end-point discovery. This document extends BGP-MP
to carry the tunnel end information to the other side of the IPv6
backbone to setup of a stateless 4over6 tunnel on the dual-stack
Provider Edge (PE) router. Based on the 4over6 tunnel, the data
plane focuses on the data packet forwarding process with
encapsulation and decapsulation. In order to avoid redundant
definition of packet encapsulation, this document reuses the existing
techniques in this part.
Wu, et al. Expires March 13, 2007 [Page 3]
Internet-Draft 4over6 September 2006
2. Terminology
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].
2.1 4over6-related terminology
4over6
A technology of IPv4 packet transmission over IPv6 networks.
4over6 PE Router
A dual-stack provider edge router connecting IPv4 access networks and
an IPv6 backbone with 4over6 functionality.Since the 4over6
technology is aways employed at the PE rout, 4over6 PE Router is
refered as to 4over6 Router in this draft.
4over6 Virtual Interface
A virtual interface with configured both IPv4 and IPv6 addresses on
the 4over6 PE router, where the encapsulated 4over6 packet is
generated. 4over6 virtual interface is abbreviated as 4over6 VIF.
4over6 Encapsulation Table
A table maintained on AFBR consisting of mappings from destination
IPv4 network address with mask to a specific IPv6 address.
Wu, et al. Expires March 13, 2007 [Page 4]
Internet-Draft 4over6 September 2006
3. Intra-domain 4over6 framework
In the IPv4/v6 interconnected network topology shown in figure 1, a
number of P routers, only running the IPv6 network stack, compose a
native IPv6 backbone. In order to provide IPv4 access to the current
IPv4 users/applications, PE routers run both IPv6 and IPv4 stacks.
The IPv6 backbone acts as a transit core to transport IPv4 packets
over the IPv6 backbone. Therefore, each of IPv4 access islands can
communicate with each other via the virtual softwires over the IPv6
transit core. The functionality of IPv4 connections over IPv6
backbone is called 4over6.
._._._._ ._._._._
| IPv4 | | IPv4 |
|access | |access |
|island | |island |
._._._._ ._._._._
| |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
[Peering PE] [Peering PE]
| |
__+____________________+__
/ : : : : \ IPv6 only
softwires | : : : : | transit core
between | : [P] : | with multiple
PEs | : : : : | [P routers]
| : : : : |
\_._._._._._._._._._._._._./
| / \ |
[Peering PE] [Peering PE]
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| | |
._._._._ ._._._._
| IPv4 | | IPv4 |
|access | |access |
|island | |island |
._._._._ ._._._._
Figure 1: IPv4 over IPv6 network topology
In addition to a general router and network topology, all additional
things to implement 4over6 are 4over6 routing and 4over forwarding on
the dual-stack PE routers.
The IPv4 access island often uses default routing to a particular PE
router on the IPv4 stack. However, since there are multiple PE
Wu, et al. Expires March 13, 2007 [Page 5]
Internet-Draft 4over6 September 2006
routers connected to an IPv6 transit core, in order to forward the
IPv4 packet directly to an egress PE router with encapsulation
mechanism, the ingress PE router needs to know which PE should be the
egress one. BGP-MP will be extended to carry the destination IPv4
networks over the IPv6 backbone. Section 4 presents the definition
of 4over6 protocol field in BGP-MP and section 5 describes the
extended behavior of BGP-MP.
After ingress PE router finds the exact egress PE router, ingress one
will use a particular encapsulation method to forward the original
IPv4 packet over the IPv6 backbone. Receiving the encapsulated
packet from the IPv6 transit core, the egress router will decapsulate
the packet to its original IPv4 format and then forwards the packet
to its final IPv4 destination. Section 6 describes the procedure of
packet forwarding.
Wu, et al. Expires March 13, 2007 [Page 6]
Internet-Draft 4over6 September 2006
4. 4over6 packet forwarding
4over6 packet forwarding includes the following 3 parts:
encapsulation of the incoming IPv4 packet with IPv6 header;
transmission of the encapsulated packet over the IPv6 transit
backbone; and decapsulation to the original IPv4 format. Since the
IPv6 transit backbone is unaware of the transmitted packet, the
transmission of the encapsulated packet is as usual as other IPv6
packet on the IPv6 backbone. As characteristics of 4over6 packet
forwarding, both encapsulation and decapsulation are processed on the
PE routers, so they will be described further as follows.
Tunnel from Ingress PE to Egress PE
----------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ +--+ +--+ +-+
|S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D|
+-+ +--+ +--+ +-+
Original Ingress Egress Original
Packet 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 4over6 AFBR routers. Figure 3 shows the format of packet
encapsulation and decapsulation.
Wu, et al. Expires March 13, 2007 [Page 7]
Internet-Draft 4over6 September 2006
+----------------------------------//-----+
| 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 4over6 PE router
Each or 4over6 router maintain an Encapsulation Table, as shown in
Figure 4. Each item in the encapsulation table consists of the
destination IPv4 network address and its mask, and the IPv6 4over6
VIF address of the corresponding advertising AFBR.
+-------------+------------------------+
| IPv4 Prefix | IPv6 Advertising AFBR |
+-------------+------------------------+
Figure 4: Encapsulation Table
When an IPv4 packet is coming into IPv6 backbone on the dual-stack PE
router, the PE is called ingress 4over6 PE router or tunnel entry-
point node, on which the IPv4 packet is encapsulated by a new IPv6
header. In this IPv6 header, the source IPv6 address is the IPv6
address of the virtual 4over6 interface on this PE, while the
destination IPv6 address is the one of the next hop of the
corresponding route maintained by BGP 4over6 extensions. When an
encapsulated 4over6 packet is coming out of the IPv6 backbone on the
dual-stack PE router, the PE is called egress 4over6 PE router or
tunnel exit-point node, on which the encapsulated packet is
Wu, et al. Expires March 13, 2007 [Page 8]
Internet-Draft 4over6 September 2006
decapsulated to its original IPv4 format.
Details of packet encapsulation and decapsulation should refer to the
definitions in [RFC2473]. In addition to such encapsulation with
IPv4 over IPv6 described in [RFC2473], other existing method like GRE
tunnel [RFC2784] can also be used directly for 4over6 encapsulation.
Furthermore, 4over6 encapsulation can also use emerging technologies
for IPv4 encapsulation over IPv6.
Wu, et al. Expires March 13, 2007 [Page 9]
Internet-Draft 4over6 September 2006
5. BGP-MP 4over6 protocol definition
[BGP-MP] defines the multiprotocol extension of BGP to carry
different kinds of routing information [RFC2842] [RFC2858] [I-D.ietf-
idr-rfc2858bis]. Optional parameter in the OPEN message indicates
the capability of BGP entity by Address Family Identifier (AFI) and
Subsequent Address Family Identifier (SAFI). The Path attribute
MP_REACH_NLRI (Type Code 14) in BGP UPDATE Message includes AFI,
SAFI, Network Address of Next Hop, and Network Layer Reachability
Information (NLRI), as shown in figure 5.
+---------------------------------------------------------+
| Address Family Identifier (2 octets): AFI_IP4=1 |
+---------------------------------------------------------+
| Subsequent AFI (1 octet): SAFI_4OVER6 = 67 |
+---------------------------------------------------------+
| Length of Next Hop (1 octet): 16 |
+---------------------------------------------------------+
| Next Hop: IPv6 Address of 4over6 Virtual Interface |
+---------------------------------------------------------+
| Reserved(1 octet) |
+---------------------------------------------------------+
| NLRI (variable): Destination IPv4 Network Address |
+---------------------------------------------------------+
Figure 5: Path attribute MP_REACH_NLRI in BGP UPDATE Message
4over6 BGP extension takes AFI as AFI_IP4=1, as the UPDATE message
contains IPv4 routing information, and defines SAFI as SAFI_4OVER6 =
67, as SAFI values 67 was assigned by IANA for 4over6 BGP extension.
4over6 BGP extension uses the above AFI and SAFI to indicate the
4over6 capability in its OPEN message, and to describe the 4over6
routing information in its Path attribute within UPDATE Message.
The path attribute MP_UNREACH_NLRI (Type Code 15) is set accordingly
similar to MP_REACH_NLRI.
Each PE router with 4over6 functionality should maintain a 4over6
virtual interface with both IPv4 address and IPv6 address. In the
path attribute, Network Address of Next Hop should be IPv6 interface
address, while the NLRI contains the destination IPv4 network address
and corresponding IPv4 network prefix.
Wu, et al. Expires March 13, 2007 [Page 10]
Internet-Draft 4over6 September 2006
6. Behavior of BGP-MP 4over6 extension
Standing on the edge between IPv4 address family and IPv6 address
family, each PE router with 4over6 functionality should run both IPv4
and IPv6 stack as AFBR.
The PE router has at least one IPv4 interface connecting with IPv4
access networks. It can use either IGP or EGP routing protocol to
learn the local IPv4 routing information on the IPv4 network.
Configured static routing may be also used on the IPv4 network.
Similarly, the PE router has at least one IPv6 interface connecting
with IPv6 transit backbone. The 4over6 I-BGP entity should setup the
peering relationship with other 4over6 PE routers on the edge of IPv6
backbone. The 4over6 I-BGP should have the 4over6 capability defined
in the above section. However, the routing among the PE routers in
inter-AS scenario is more complicated than the intra-AS case. The
methods in [RFC4364] can be leveraged to support softwire signaling,
routing and encapsulation across inter-AS topologies.Anyway a light-
weighted solution is mostly prefered to solve the problem. This
document just addresses the routing issue among PE routers in the
same AS.
6.1 Receiving routing information from CE
When a 4over6 PE router learns routing information about the local
edge network, the 4over6 I-BGP entity should have following
functions.
1. The 4over6 I-BGP entity should maintain the local IPv4 routing
information it learns from the local IPv4 access network or
configuration.
2. Construct new items in local encapsulation table. IPv4
destination should be set with proper prefix with the local IPv4
routing information it learns. The PE router uses the IPv6
address on its 4over6 VIF to set the advertising router.
3. The 4over6 I-BGP entity should broadcast the local IPv4 routing
information to its peers by BGP-MP with 4over6 BGP extension.
* Taking AFI as AFI_IP4=1 and SAFI as SAFI_4OVER6 = 67.
* Destination network address should be the original destination
IPv4 network address.
* Nexthop should be the IPv6 address of its 4over6 virtual
interface.
Wu, et al. Expires March 13, 2007 [Page 11]
Internet-Draft 4over6 September 2006
6.2 Receiving routing information from PE
For a local PE running 4over6 I-BGP protocol, if the remote peering
PE learns new routing information from static configuration or
dynamic routing protocol from its local CEs, the remote peering PE
will send the corresponding routing information to the local one.
Then, the local PE will process the routing information as follows.
1. Confirm the type of received routing information.
* Confirm AFI as AFI_IP4=1;
* Confirm SAFI as SAFI_4OVER6 = 67;
* Confirm destination in NLRI is in IPv4 AF;
* Confirm the next hop is in IPv6 AF.
2. Add new items in the encapsulation table
* Use the destination network address as the received original
destination IPv4 network address;
* Set the corresponding advertising router as the Next Hop field
in the BGP UPDATE message.
3. Add a new routing item in the IPv4 routing table
* Use the destination network address as the received original
destination IPv4 network address;
* Set the Next Hop as N/A.
* Set the OUTPUT IF as the 4over6 virtual interface on the PE
router.
Wu, et al. Expires March 13, 2007 [Page 12]
Internet-Draft 4over6 September 2006
7. 4over6 Error Processing
Because 4over6 reuses existing encapsulation technologies, Error
Processing should be also reused as much as possible. In the data
plane of packet forwarding process, error reporting and processing
should be refered to [RFC2473]. In the control plane of I-BGP
peering communication, error reporting and processing should be
refered to [RFC4271].
Wu, et al. Expires March 13, 2007 [Page 13]
Internet-Draft 4over6 September 2006
8. Implementation and deployment
In addtion to the 4over6 softwire mechanism mentioned in the draft,
4over6 technology was implemented and deployed in CERNET2 (The Next
Generation China Education and Research Network). Figure 6 shows
4over6 implementation network topology.
+-----------------------------------------------------+
| IPv6 (CERNET2) |
| |
+-----------------------------------------------------+
| | | |
| | | |
+------+ +------+ +------+ +------+
|4over6| ... |4over6| |4over6| ... |4over6|
|router| |router| |router| |router|
+------+ +------+ +------+ +------+
| | | |
| | | |
| | | |
+-----------+ +-----------+ +-----------+ +-----------+
|IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access|
| network | | network | | network | | network |
+-----------+ +-----------+ +-----------+ +-----------+
| |
+----------------------+
| IPv4 (Internet) |
| |
+----------------------+
Figure 6: 4over6 implementation network topology
This implementation and deployment is just to test the function and
prove the efficiency of 4over6 technology. There are some IPv4
access networks, which run only IPv4 stack, equiped with some server
and client running different applications. CERNET2 is the transit
core running only IPv6 protocol. Just as the figure shows that some
IPv4 access networks are conneted to both IPv6 and IPv4 networks and
others are only connected to IPv6 backbones. In our deployment users
in different IPv4 networks can communicate with each other through
4over6 softwire mechanism or just ordinary IPv4 network.
Wu, et al. Expires March 13, 2007 [Page 14]
Internet-Draft 4over6 September 2006
9. Extension to IPv6 over IPv4
From the technical view the 4over6 mechanism does not involve any
IPv4/v6 address translation techniques such as IPv4-embeded IPv6
address or manual configuration. Therefore, it can be extended
smoothly for the IPv6 over IPv4 scenarios in which the existing IPv4
networks act as the transit core to connected the IPv6 islands. The
only defference is that the AFI field should be set as AFI_IP6=2
since in the UPDATE massage the carried destination prefix is IPv6
networks. The SAFI can just use the SAFI_4OVER6=67 to indicate the
capability of the BGP entity.
Wu, et al. Expires March 13, 2007 [Page 15]
Internet-Draft 4over6 September 2006
10. IANA Considerations
In order to indicate the capability of 4over6 in the OPEN message,
4over6 mechanism need a Subsequent Address Family Identifier (SAFI).
As SAFI was allocated in a FCFS policy for number 64-128, SAFI value
67 was assigned by IANA for 4over6 BGP extension : SAFI_4OVER6.
Wu, et al. Expires March 13, 2007 [Page 16]
Internet-Draft 4over6 September 2006
11. 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 a particular flow or maintain the state of a particular 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 security communications.
Wu, et al. Expires March 13, 2007 [Page 17]
Internet-Draft 4over6 September 2006
12. Changes from -00
1. Remove the confusion of figure number.
2. Revising the figure for the encapsulation table
3. Changing the AFI field to AFI_IPV4 =1, as the UPDATE massage
carries the IPv4 NLRI information.
4. Adding the some discussion about the inter-AS consideration and
RFC4364 is added as a reference .
5. Describing the fact that SAFI values 67 has been assigned by IANA
for 4over6 BGP extension: SAFI_4OVER6
6. Adding two new section about the deloyment of 4over6 mechanism
and the extension to IPv6 over IPv4.
7. Revising the format of MP_REACH_NLRI attribut according to
[I-D.ietf-idr-rfc2858bis].
8. Further linguistic clarificatons and edits
Wu, et al. Expires March 13, 2007 [Page 18]
Internet-Draft 4over6 September 2006
13. Conclusion
Due to the rapid deployment of IPv6 networks, especially IPv6
backbones, these IPv6 backbones may need to provide the access of
existing IPv4 networks to support long lived IPv4 applications as
IPv6 transit core. For the complex IPv4/v6 interconnection, this
document describes an automatic tunnel endpoint discovery for
transmission of IPv4 over IPv6 by BGP 4over6 extensions. The
provider core routers (P router) only runs with native IPv6, and the
provider edge (PE) router runs in dual stacks. In the control plane,
4over6 PE router maintains an I-BGP peering relationship with each
other, and sends the routing information of local IPv4 access network
to other peers. In the data plane, PE router encapsulates local IPv4
packets and decapsulates the tunnel packet to its original IPv4
format to its destination IPv4 networks. Therefore, this 4over6
solution with 4over6 BGP extensions only needs to enhance the 4over6
functionality on the PE routers, while there is no need to change P
routers and custom routers.
Wu, et al. Expires March 13, 2007 [Page 19]
Internet-Draft 4over6 September 2006
14. Acknowledgements
During the design procedure of the 4over6 framework and definition of
BGP-MP 4over6 extension, Professor Ke Xu and Professor Mingwei Xu
gave the authors many valuable suggestions. 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.
Wu, et al. Expires March 13, 2007 [Page 20]
Internet-Draft 4over6 September 2006
15. References
15.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.
15.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-problem-statement]
Li, X., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-02 (work in
progress), I-D Status active, May 2006.
Wu, et al. Expires March 13, 2007 [Page 21]
Internet-Draft 4over6 September 2006
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: cuiyong@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
Wu, et al. Expires March 13, 2007 [Page 22]
Internet-Draft 4over6 September 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wu, et al. Expires March 13, 2007 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:31 |