doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5747.txt b/doc/rfc/rfc5747.txt
new file mode 100644
index 0000000..4190a75
--- /dev/null
+++ b/doc/rfc/rfc5747.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Independent Submission                                             J. Wu
+Request for Comments: 5747                                        Y. Cui
+Category: Experimental                                             X. Li
+ISSN: 2070-1721                                                    M. Xu
+                                                     Tsinghua University
+                                                                 C. Metz
+                                                     Cisco Systems, Inc.
+                                                              March 2010
+
+
+  4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
+
+Abstract
+
+   The emerging and growing deployment of IPv6 networks will introduce
+   cases where connectivity with IPv4 networks crossing IPv6 transit
+   backbones is desired.  This document describes a mechanism for
+   automatic discovery and creation of IPv4-over-IPv6 tunnels via
+   extensions to multiprotocol BGP.  It is targeted at connecting
+   islands of IPv4 networks across an IPv6-only backbone without the
+   need for a manually configured overlay of tunnels.  The mechanisms
+   described in this document have been implemented, tested, and
+   deployed on the large research IPv6 network in China.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5747.
+
+IESG Note
+
+   The mechanisms and techniques described in this document are related
+   to specifications developed by the IETF softwire working group and
+   published as Standards Track documents by the IETF, but the
+   relationship does not prevent publication of this document.
+
+
+
+Wu, et al.                    Experimental                      [Page 1]
+
+RFC 5747                         4over6                       March 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. 4over6 Framework Overview .......................................3
+   3. Prototype Implementation ........................................5
+      3.1. 4over6 Packet Forwarding ...................................5
+      3.2. Encapsulation Table ........................................6
+      3.3. MP-BGP 4over6 Protocol Extensions ..........................7
+           3.3.1. Receiving Routing Information from Local CE .........8
+           3.3.2. Receiving 4over6 Routing Information from a
+                  Remote 4over6 PE ....................................8
+   4. 4over6 Deployment Experience ....................................9
+      4.1. CNGI-CERNET2 ...............................................9
+      4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network ............9
+      4.3. Deployment Experiences ....................................10
+   5. Ongoing Experiment .............................................11
+   6. Relationship to Softwire Mesh Effort ...........................12
+   7. IANA Considerations ............................................12
+   8. Security Considerations ........................................13
+   9. Conclusion .....................................................13
+   10. Acknowledgements ..............................................13
+   11. Normative References ..........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                      [Page 2]
+
+RFC 5747                         4over6                       March 2010
+
+
+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.  As a result, IPv6 networks and IPv4
+   applications/hosts will have to coexist for a long period of time.
+
+   The emerging and growing deployment of IPv6 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 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 at the time that the
+   mechanism described in this document was introduced, most of these
+   existing techniques focused on the problem of IPv6 over IPv4, rather
+   than the case of IPv4 over IPv6.  Encapsulation methods alone, such
+   as those defined in [RFC2473], require manual configuration in order
+   to operate.  When a large number of tunnels are necessary, manual
+   configuration can become burdensome.  To the above problem, this
+   document describes an approach, 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
+   set up an IPv4-over-IPv6 tunnel in an automatic and scalable fashion
+   between a large number of edge routers.  This document describes
+   experimental extensions to Multiprotocol Extension for BGP (MP-BGP)
+   [RFC4271] [RFC4760] employed to communicate tunnel endpoint
+   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.
+
+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 the IPv4 access islands to communicate with one
+   another via 4over6 tunnels spanning the IPv6 transit core.
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                      [Page 3]
+
+RFC 5747                         4over6                       March 2010
+
+
+                       _._._._._            _._._._._
+                      |  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
+   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.                    Experimental                      [Page 4]
+
+RFC 5747                         4over6                       March 2010
+
+
+3.  Prototype Implementation
+
+   An implementation 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
+   three 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 performed 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 decapsulation are both
+   on the dual-stack 4over6 PE routers.  Figure 3 shows the format of
+   packet encapsulation and decapsulation.
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                      [Page 5]
+
+RFC 5747                         4over6                       March 2010
+
+
+                           +----------------------------------//-----+
+                           | 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.                    Experimental                      [Page 6]
+
+RFC 5747                         4over6                       March 2010
+
+
+        +-------------+------------------------------------------------+
+        | IPv4 Prefix | IPv6 Advertising Address Family Border Router  |
+        +-------------+------------------------------------------------+
+
+                      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
+   (Internal BGP) 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 (China Next Generation Internet -
+   China Education and Research Network) national IPv6 backbone used in
+   the testing and deployment of this solution.
+
+
+
+
+
+
+Wu, et al.                    Experimental                      [Page 7]
+
+RFC 5747                         4over6                       March 2010
+
+
+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 the 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 Subsequent Address Family Identifier (SAFI) BGP 4over6 (67)
+       has been assigned by IANA.  We call a BGP update with a SAFI of
+       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
+   the correctness of the received attribute, the following procedures
+   are used to update the local encapsulation table and redistribute new
+   information to the 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 the local
+       encapsulation table.)
+
+
+
+Wu, et al.                    Experimental                      [Page 8]
+
+RFC 5747                         4over6                       March 2010
+
+
+   4.  Install and maintain a new entry in the encapsulation table with
+       the extracted IPv4 prefix and its corresponding IPv6 address.
+
+   5.  Redistribute the new 4over6 routing information to the 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.
+
+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 (CPNs) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                      [Page 9]
+
+RFC 5747                         4over6                       March 2010
+
+
+         +-----------------------------------------------------+
+         |                    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
+   running different applications.  The 4over6 PE routers are deployed
+   at 8 x IPv6 nodes of CNGI-CERNET2, located in seven universities and
+   five 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 occurred.
+   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:
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 10]
+
+RFC 5747                         4over6                       March 2010
+
+
+   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 (e.g., MSN, Google Talk), and
+   Multimedia Streaming, all functioned correctly.
+
+5.  Ongoing Experiment
+
+   Based on the above successful experiment, we are going to have
+   further experiments in the following two aspects.
+
+   1.  Inter-AS 4over6
+
+      The above experiment is only deployed over a single AS.  With the
+      growth of the network, there could be multiple ASes between the
+      edge networks.  Specifically, the Next Hop field in MP-BGP
+      indicates the tunnel endpoint in the current 4over6 technology.
+      However, in the Inter-AS scenario, the tunnel endpoint needs to be
+      separated from the field of Next Hop.  Moreover, since the
+      technology of 4over6 is deployed on the router running MP-BGP, the
+      supportability of 4over6 on each Autonomous System Border Router
+      (ASBR) will be a main concern in the Inter-AS experiment.  We may
+      consider different situations: (1) Some ASBRs do not support
+      4over6; (2) ASBRs only support the 4over6 control plane (i.e., MP-
+      BGP extension of 4over6) rather than 4over6 data plane; (3) ASBRs
+      support both the control plane and the data plane for 4over6.
+
+   2.  Multicast 4over6
+
+      The current 4over6 technology only supports unicast routing and
+      data forwarding.  With the deployment of network-layer multicast
+      in multiple IPv4 edge networks, we need to extend the 4over6
+      technology to support multicast including both multicast tree
+      manipulation on the control plane and multicast traffic forwarding
+      on the data plane.  Based on the current unicast 4over6 technology
+      providing the unicast connectivity of edge networks over the
+      backbone in another address family, the multicast 4over6 will
+      focus on the mapping technologies between the multicast groups in
+      the different address families.
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 11]
+
+RFC 5747                         4over6                       March 2010
+
+
+6.  Relationship to Softwire Mesh Effort
+
+   The 4over6 solution was presented at the IETF Softwires Working Group
+   Interim meeting in Hong 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 -- an IPv6 backbone that offers transit to attached client
+   IPv4 networks.
+
+   The 4over6 solution can be viewed as a precursor to the Softwire Mesh
+   Framework proposed in the softwire problem statement [RFC4925].
+   However, there are several differences with this solution and the
+   effort that emerged from the Softwires Working Group called "softwire
+   Mesh Framework" [RFC5565] and the related solutions [RFC5512]
+   [RFC5549].
+
+   o  MP-BGP Extensions. 4over6 employs a new SAFI (BGP 4over6) to
+      convey client IPv4 prefixes between 4over6 PE routers.  Softwire
+      Mesh retains the original AFI-SAFI designations, but it uses a
+      modified MP_REACH_NLRI format to convey IPv4 Network Layer
+      Reachability Information (NLRI) prefix information with an IPv6
+      next_hop address [RFC5549].
+
+   o  Encapsulation. 4over6 assumes IP-in-IP or it is possible to
+      configure Generic Routing Encapsulation (GRE).  Softwires uses
+      those two scenarios configured locally or for IP headers that
+      require dynamic updating.  As a result, the BGP encapsulation SAFI
+      is introduced in [RFC5512].
+
+   o  Multicast.  The basic 4over6 solution only implemented unicast
+      communications.  The multicast communications are specified in the
+      Softwire Mesh Framework and are 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 Softwire Mesh Framework supports both 4over6
+      and 6over4.
+
+7.  IANA Considerations
+
+   A new SAFI value (67) has been assigned by IANA for the BGP 4over6
+   SAFI.
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 12]
+
+RFC 5747                         4over6                       March 2010
+
+
+8.  Security Considerations
+
+   Tunneling mechanisms, especially automatic ones, often have potential
+   problems of Distributed Denial of Service (DDoS) attacks on the
+   tunnel entry-point or tunnel exit-point.  As the advantage, the BGP
+   4over6 extension doesn't allocate resources to a single flow or
+   maintain the state for a flow.  However, since the IPv6 tunnel
+   endpoints are globally reachable IPv6 addresses, it would be trivial
+   to spoof IPv4 packets by encapsulating and sending them over IPv6 to
+   the tunnel interface.  This could bypass IPv4 Reverse Path Forwarding
+   (RPF) or other antispoofing techniques.  Also, any IPv4 filters may
+   be bypassed.
+
+   An iBGP peering relationship may be maintained over IPsec or other
+   secure communications.
+
+9.  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
+   data plane as IPv4 packets are tunneled through the IPv6 backbone.
+
+   An actual implementation has been developed and deployed on the CNGI-
+   CERNET2 IPv6 backbone.
+
+10.  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 the IETF Softwires WG is also
+   gratefully acknowledged with special thanks to David Ward, Alain
+   Durand, and Mark Townsley for their rich experience and knowledge in
+   this field.  Yakov Rekhter provided helpful comments and advice.
+   Mark Townsley reviewed this document carefully and gave the authors a
+   lot of valuable comments, which were very important for improving
+   this document.
+
+   The deployment and test for the prototype system was conducted among
+   seven universities -- namely, Tsinghua University, Peking University,
+   Beijing University of Post and Telecommunications, Shanghai Jiaotong
+   University, Huazhong University of Science and Technology, Southeast
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 13]
+
+RFC 5747                         4over6                       March 2010
+
+
+   University, and South China University of Technology.  The authors
+   would like to thank everyone involved in this effort at these
+   universities.
+
+11.  Normative References
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, December 1998.
+
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+              "Multiprotocol Extensions for BGP-4", RFC 4760,
+              January 2007.
+
+   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
+              Problem Statement", RFC 4925, July 2007.
+
+   [RFC5512]  Mohapatra, P. and E. Rosen, "The BGP Encapsulation
+              Subsequent Address Family Identifier (SAFI) and the BGP
+              Tunnel Encapsulation Attribute", RFC 5512, April 2009.
+
+   [RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
+              Layer Reachability Information with an IPv6 Next Hop",
+              RFC 5549, May 2009.
+
+   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
+              Framework", RFC 5565, June 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 14]
+
+RFC 5747                         4over6                       March 2010
+
+
+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
+
+   Chris Metz
+   Cisco Systems, Inc.
+   3700 Cisco Way
+   San Jose, CA  95134
+   USA
+   EMail: chmetz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                    Experimental                     [Page 15]
+