Network Working Group                                              J. Wu
Internet-Draft                                                    Y. Cui
Expires: August 26, 2006                                           X. Li
                                                     Tsinghua University
                                                       February 22, 2006

        4over6 Transit using Encapsulation and BGP-MP Extension

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Due to the rapid deployment of IPv6 networks, especially IPv6
   backbones, the existing long-live IPv4 networks are 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 becomes large and the IPv4/v6 interconnection

Wu, et al.               Expires August 26, 2006                [Page 1]

Internet-Draft                   4over6                    February 2006

   topology becomes complex.  Therefore, the manual configuration to a
   large number of these end-2-end tunnels will be 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  . . . . . . . . . . . . . 12
     6.1.  Receiving routing information from CE  . . . . . . . . . . 12
     6.2.  Receiving routing information from PE  . . . . . . . . . . 12

   7.  4over6 Error Processing  . . . . . . . . . . . . . . . . . . . 14

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

   10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . . . . . . . . . . . . . . . 19

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Wu, et al.               Expires August 26, 2006                [Page 2]

Internet-Draft                   4over6                    February 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 August 26, 2006                [Page 3]

Internet-Draft                   4over6                    February 2006

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.1.  4over6-related terminology


   A framework 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.

   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 August 26, 2006                [Page 4]

Internet-Draft                   4over6                    February 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 August 26, 2006                [Page 5]

Internet-Draft                   4over6                    February 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 August 26, 2006                [Page 6]

Internet-Draft                   4over6                    February 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
   +-+            +--+                        +--+            +-+
   +-+            +--+                        +--+            +-+
   Original     Ingress                      Egress         Original
   Packet                                                   Packet
   Source                                                   Destination
   Node                                                     Node

   Figure 1: Packet forwarding along 4over6 Tunnel

   As shown in Figure 1, packet encapsulation and decapsulaion are both
   on the 4over6 AFBR routers.  Figure 2 shows the format of packet
   encapsulation and decapsulation.

Wu, et al.               Expires August 26, 2006                [Page 7]

Internet-Draft                   4over6                    February 2006

                           | IPv4 Header |   Packet Payload          |
                            <         Original IPv4 Packet           >
                                         |(Encapsulation on ingress PE)
    < Tunnel IPv6 Headers > <         Original IPv4 Packet           >
   +-----------+ - - - - - +-------------+-----------//--------------+
   |   IPv6    | IPv6      |   IPv4      |                           |
   |           | Extension |             |      Packet Payload       |
   |   Header  | Headers   |  Header     |                           |
   +-----------+ - - - - - +-------------+-----------//--------------+
    <                      Tunnel IPv6 Packet                       >
                                         |(Decapsulation on egress PE)
                           | IPv4 Header |   Packet Payload          |
                            <         Original IPv4 Packet           >

   Figure 2: Packet encapsulation and decapsulation on 4over6 PE router

   Each 4over6 router maintain an Encapsulation Table, as shown in
   Figure 3.  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.

         | Length of prefix | IPv4 Prefix | IPv6 Advertising AFBR  |
         | Length of prefix | IPv4 Prefix | IPv6 Advertising AFBR  |
         |                      ......                             |
         |                                                         |

   Figure 3: 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

Wu, et al.               Expires August 26, 2006                [Page 8]

Internet-Draft                   4over6                    February 2006

   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
   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 August 26, 2006                [Page 9]

Internet-Draft                   4over6                    February 2006

5.  BGP-MP 4over6 protocol definition

   [BGP-MP] defines the multiprotocol extension of BGP to carry
   different kinds of routing information [RFC2842] [RFC2858].  Optional
   parameter in the OPEN message indicates the capability of BGP entity
   by Address Family Identifier (AFI) and Subsequent Address Family
   Identifier (SAFI).  Path attribute in BGP UPDATE Message includes
   AFI, SAFI, Network Address of Next Hop, and Network Layer
   Reachability Information (NLRI), as shown in figure 4.

         | Address Family Identifier (2 octets): AFI_IP6=2         |
         | Subsequent AFI (1 octet): SAFI_4OVER6 = 67              |
         | Length of Next Hop (1 octet): 16                        |
         | Next Hop: IPv6 Address of 4over6 Virtual Interface      |
         | Number of SNPAs (1 octet)                               |
         | Length of first SNPA(1 octet)                           |
         | First SNPA (variable)                                   |
         | Length of second SNPA (1 octet)                         |
         | Second SNPA (variable)                                  |
         | ...                                                     |
         | Length of Last SNPA (1 octet)                           |
         | Last SNPA (variable)                                    |
         | NLRI (variable): Destination IPv4 Network Address       |

   Figure 4: Path attribute in BGP UPDATE Message

   4over6 BGP extension takes AFI as AFI_IP6=2, and defines SAFI as
   SAFI_4OVER6 = 67, based on the FCFS policy of SAFI application.
   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.

   Each PE router with 4over6 functionality should maintain a 4over6
   virtual interface with both IPv4 address and IPv6 address.  In the

Wu, et al.               Expires August 26, 2006               [Page 10]

Internet-Draft                   4over6                    February 2006

   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 August 26, 2006               [Page 11]

Internet-Draft                   4over6                    February 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.

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

   1.  The 4over6 I-BGP entity should maintain the local IPv4 routing
       information it learns from the local IPv4 access network or

   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_IP6=2 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

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

Wu, et al.               Expires August 26, 2006               [Page 12]

Internet-Draft                   4over6                    February 2006

   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_IP6=2;

       *  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

Wu, et al.               Expires August 26, 2006               [Page 13]

Internet-Draft                   4over6                    February 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 August 26, 2006               [Page 14]

Internet-Draft                   4over6                    February 2006

8.  IANA Considerations

   As stated above, this document requests that IANA assigns a
   Subsequent Address Family Identifier (SAFI).  Since SAFI is allocated
   in a FCFS policy for number 64-128, 4over6 BGP extension applies for
   SAFI number, SAFI_4OVER6, at 67.

Wu, et al.               Expires August 26, 2006               [Page 15]

Internet-Draft                   4over6                    February 2006

9.  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 August 26, 2006               [Page 16]

Internet-Draft                   4over6                    February 2006

10.  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 August 26, 2006               [Page 17]

Internet-Draft                   4over6                    February 2006

11.  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.

Wu, et al.               Expires August 26, 2006               [Page 18]

Internet-Draft                   4over6                    February 2006

12.  References

12.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.

12.2.  Informative References

              Li, X., "Softwire Problem Statement",
              draft-ietf-softwire-problem-statement-00 (work in
              progress), December 2005.

Wu, et al.               Expires August 26, 2006               [Page 19]

Internet-Draft                   4over6                    February 2006

Authors' Addresses

   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5983

   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5822

   Xing Li
   Tsinghua University
   Department of Electronic Engineering, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5983

Wu, et al.               Expires August 26, 2006               [Page 20]

Internet-Draft                   4over6                    February 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Wu, et al.               Expires August 26, 2006               [Page 21]