Internet DRAFT - draft-xu-savi-transition


SAVI                                            K.Xu, G.Hu, J.Bi, M.Xu
Internet Draft                                          Tsinghua Univ.
Intended status: Standard Tracks                                F.Shi
Expires: May 2019                                        China Telecom
                                                       November 5,2018

     A General Framework of Source Address Validation and Traceback for
                      IPv4/IPv6 Transition Scenarios


   SAVI (Source Address Validation Improvement) is an excellent
   mechanism for anti-IP-spoofing, which was advocated by IETF but only
   focused on single-stack or simple network scenarios right now. To the
   best of our knowledge, existing studies have not paid attention to
   the IPv4/IPv6 transition scenarios. However, since IPv4/IPv6
   transition schemes are plenty and various, one solution cannot meet
   all requirements of them. In this draft, we present a SAVI-based
   general framework for IP source address validation and traceback in
   the IPv4/IPv6 transition scenarios, which achieve this by extracting
   out essential and mutual properties from these schemes, and forming
   sub-solutions for each property. When one transition scheme is
   composed from various properties, its IP source address validation
   and traceback solution is directly comprised by the corresponding
   sub-solutions. Thus, the most exciting advantage of this framework is
   that it is a once-and-for-all solution no matter how transition
   schemes change. Till now, this proposal was approved by China
   Communications Standards Association (CCSA), and we will actively
   promote it to apply real network scenarios.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at

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

Xu, et al.                Expires May 4 2019                 [Page 1]
Internet-Draft             SAVI Transition               November 2018

   This Internet-Draft will expire on May 4, 2019.

Copyright Notice

   Copyright (c) 2015 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. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

    (This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10
   2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.   Introduction .............................................. 3
   2.   Conventions used in this document ......................... 4
   3.   Framework description ..................................... 5
      3.1. Property Extraction .................................... 5
      3.2. Solutions of IP source address validation .............. 7
      3.3. Solutions to IP source address traceback .............. 10
   4.   Framework verification ................................... 13
      4.1. Public 4over6 ......................................... 13
      4.2. 6RD ................................................... 14
      4.3. DS-Lite ............................................... 14
      4.4. 4RD ................................................... 15
      4.5. A+P ................................................... 15
      4.6. IVI ................................................... 15
   5.   Framework implementation.................................. 15
   6.   Conclusions .............................................. 16

Xu, et al.                Expires May 4 2019                 [Page 2]
Internet-Draft             SAVI Transition               November 2018

   7.   References ............................................... 17
      7.1. Normative References .................................. 17
   8.   Acknowledgments .......................................... 18

1. Introduction

   The issue of IP source address spoofing has become very serious in
   recent years. According to the IP spoofer project of MIT, the
   proportion of spoofable netblocks, IP addresses and autonomous
   systems are 14.6%, 16.3%, 23.9%, respectively [MITSpoofer]. This was
   result from the absence of intrinsic mechanism of IP source address
   validation. Encouragingly, this issue was noticed gradually by many
   researchers and lots of excellent solutions were proposed. One of
   them is the SAVI [SAVI] (Source Address Validation Improvement)
   scheme which is proposed by IETF SAVI workgroup. The mechanism of it
   is binds host's IP, MAC address, uplink port in the user access
   switch by snooping host's IP assignment protocol. The switch which
   followed the SAVI proposal, namely SAVI Switch, eliminates this issue
   in the first-hop of packets. Binding function in SAVI Switch is
   automatically accomplished by snooping IP address assignment
   protocols, e.g. DHCPv6, SLAAC. Thus, It is more accurate and
   effective than the URPF [RFC3704] (Unicast Reverse Path Forwarding)
   proposal because it takes effect in the position of user's layer2
   access switch rather than access router. According to the charter of
   SAVI workgroup, it would cover wire/wireless Ethernet network, and
   both protocols of IPv4 and IPv6 as well. Till now, various commodity
   SAVI Switch products have already been implemented by lots of network
   equipment providers, for instance, Huawei, ZTE etc.

   On the other hand, since bothered by stubborn issues of IPv4 Internet,
   including exhaustion of IPv4 address, people gradually turn their
   attention from IPv4 to IPv6 Internet. Most ISPs are progressively
   developing their IPv6 networks and lead to the IPv6 Internet presents
   a rapid development trend in recent years. However, in a short period,
   traditional IPv4 Internet will not disappear very soon, on the
   contrary, it will still take the dominated position for a long time
   with the reason of man-power, money cost and so on. As a matter of
   fact, the IPv6 Internet traffic only accounts for 1% of the total
   Internet traffic. In other words, the two kinds of networks will be
   coexistence for a long period. In view of this situation, plenty of
   schemes for promoting intercommunication between the two networks
   have been proposed, such as IVI[RFC6219], DS-Lite[RFC6333], 4RD[4RD],
   A+P[RFC6346] and Public 4over6[p4over6]. In the light of work mode,
   they are categorized into three types: dual-stack, translation and
   tunnel. In terms of tunnel technology, it is also known as

Xu, et al.                Expires May 4 2019                 [Page 3]
Internet-Draft             SAVI Transition               November 2018

   "softwires"[RFC5565] which provides packet transit service from one
   edge of single-protocol network to other.

   Although many mature and practical solutions have met the demand of
   validating IP source address and even traceback in single-stack
   networks, but to the best of our knowledge, ideas for the same
   purpose in the IPv4/IPv6 transition scenarios have not been explored
   yet. The difficulty lies in it is that, it's inflexible to propose
   corresponding scheme for each one plan since they are plenty and
   various. Viewed this challenge and dilemma, proposing solo general
   and feasible solution which can satisfy all the requirements of these
   transition plans has become the single goal of this draft.

   After investigated almost all the transition especially tunnel
   schemes, we have found that there exist basic and common properties
   among them. Then, we focus on extracting these essential properties
   from these schemes and then forming sub-solutions for each property
   with the help of SAVI. Consequently, when one scheme is constituted
   by required properties, its source address validation and traceback
   solution are naturally combined by corresponding sub-solutions. Thus,
   our framework is a once-and-for-all solution no matter how transition
   plans will change.

   Since authors of this draft participate in both SAVI and Softwire
   IETF workgroup long-termly, we naturally used the ideas of SAVI to
   achieve it. Like we mentioned, our purpose is present a feasible
   general anti-spoofing framework for transition scenarios and give
   more inspiration to interested people, but limited by the
   uncontrollable factors, like personal privacy, law permission,
   implementation detail, framework's performance evaluation, expanding
   SAVI out of LAN environment or not, we will not refer to.

   In addition, more of the details we have been discussed in the paper
   ''A General Framework of Source Address Validation and Traceback for
   IPv4/IPv6 Transition Scenarios'', which was published in Nov.2013
   issue of IEEE Network. Interesting reader can refer to it and discuss
   with us about your concerns in anytime.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in

Xu, et al.                 Expires May 4 2019                [Page 4]
Internet-Draft             SAVI Transition               November 2018

3. Framework description

   In this section, we firstly give the threat model and its
   considerations, and then describe our framework in detail.

   The threat model in this paper we refer to the fields in an IP packet
   can be tampered as the spoofer's will, and when these packets arrived
   their destination, spoofer can run in the attack or purposed action
   and it's hard to locate the perpetrator since the packet's source IP
   address has been modified. But we believe that the network devices or
   middle-boxes (NAT, tunnel points, protocol translator etc.) are
   trustful and attackers cannot manipulate them. Otherwise, that
   situation would become very complex and it's beyond our agenda.

   To keep packets carried with the trusted IP source address, it should
   let the packets come from an authorized user who is the owner of the
   packet's source address, and prevent spoofed packets from being
   forwarded. Naturally, the straight-forward idea of us is to deploy
   SAVI Switch into users' subnet to keep the trustiness of all hosts.
   Furthermore, NAT devices need to save the pre-translate and post-
   translate addresses mapping records. Such ideas could directly
   facilitate the implementation of the traceback function.

3.1. Property Extraction

   Like we mentioned, it is difficult to require one framework to adapt
   to all transition plans. But since there exist common properties in
   these transition schemes, establishing such framework could be
   possible if we could extract these essential properties from these
   plans and restore them by reassembling required properties. Actually,
   this has been achieved based on three property extraction rules: 1)
   It only extracts essential elements and does not take irrelevant
   details into account; 2) every element should not be further
   decomposed (in other words, each element should be atomic and unique);
   3) it should have the reconstruction capability of reassembling
   required elements. The result of the property extraction is
   illustrated as table I.

   We have summarized these properties into four categories with 12
   items. Property group A states the stacks of spoofer's running rather
   than its network environment. The stateless in Group B means that
   IPv4 and IPv6 addresses are tight related since they can be deduced
   with each other, while the stateful declares that the two kinds of
   addresses has no relation so that the tunnel terminal needs to save
   the mapping relationship for forwarding. Property items C3 and C4
   which describe the scenario where multi-hosts share one IPv4 address
   by splitting the port-range. The last property group D depicts the

Xu, et al.                Expires May 4 2019                 [Page 5]
Internet-Draft             SAVI Transition               November 2018

   positions of NAT device which could change the source IP address not
   only within the form of private to public and shared to non-shared.
   Properties D1, D2 and D3 manifest the NAT devices in the position of
   the local network, the destination network with same protocol-stack
   of the local network, and both sides separately.

   As the property item combination, we must point out two confusion
   places. The first one is A3 with group C are not conflicting with
   each other because the source host can retrieve IPv4 address by
   taking itself as tunnel start-point even in a IPv6 network, as well
   as C2 or C3 with group D since network address translation(NAT) has
   various forms not just only refer the private to the public.
   Therefore, the maximum number is 72 and the minimum is 2 since 6over4
   transition only needs A3 combine with B1 or B2, and group D is not a
   necessary condition for 4over6 transition regard to the item

                 Table I. Properties in transition schemes

   | Property Group     |Group Code | Property Name           | Value|
   |The protocol stacks |     A     | Dual-Stack              |   A1 |
   |of source host      |           |-------------------------+------+
   |                    |           | IPv4 only               |   A2 |
   |                    |           |-------------------------+------+
   |                    |           | IPv6 only               |   A3 |
   |Relationships       |     B     | Stateless               |   B1 |
   |between IPv4 and    |           |-------------------------+------+
   |IPv6 Address        |           | Stateful                |   B2 |
   |Forms of 4over6     |     C     | Private                 |   C1 |
   |hosts' IPv4 address |           +-------------------------+------+
   |                    |           | Public                  |   C2 |
   |                    |           +-------------------------+------+
   |                    |           | Public with Port Sharing|   C3 |
   |                    |           +-------------------------+------+
   |                    |           |Private with Port Sharing|   C4 |
   |The locations of NAT|     D     | Only in local side      |   D1 |
   |devices for source  |           +-------------------------+------+
   |host                |           | Only in dest.side       |   D2 |
   |                    |           +-------------------------+------+
   |                    |           | D1 & D2                 |   D3 |

Xu, et al.                Expires May 4 2019                 [Page 6]
Internet-Draft             SAVI Transition               November 2018

3.2. Solutions of IP source address validation

   Keeping packets bringing with trustful IP source addresses is the
   foundation of the traceback and other applications. SAVI Switch can
   achieve this goal, but till now, it's only applicable for the single-
   stack network, which means SAVI Switch needs to be improved to adapt
   to dual-stack and other complex scenarios. In the other sides, it is
   not inflexibility to enumerate all the possibilities of property
   combinations and separately considering how to achieve our goal.
   Instead, we present the sub-solutions to IP source address validation
   for each property with the help of SAVI Switch, as illustrated in
   table II.

     Table II. Solutions of Source address validation for each property

   | Property Name      |   Value   | Measurements in SAVI Switch    |
   | Dual-Stack         |    A1     |<IPv6, MAC, linkup-Port>        |
   | IPv4 only          |    A2     |<IPv4, MAC, linkup-Port>        |
   | IPv6 only          |    A3     |<IPv6, MAC, linkup-Port>        |
   | Stateless          |    B1     | none                           |
   | Stateful           |    B2     | none                           |
   | Private            |    C1     | none                           |
   | Public             |    C2     | none                           |
   | Public with Port-S |    C3     | property A & port-range        |
   | Private with Port-S|    C4     | property A & port-range        |
   | Near to CPE        |    D1     |                                |
   +--------------------+-----------|                                |
   | Near to CGN AFTR   |    D2     | NAT devices record the         |
   +--------------------+-----------| NAT-Table                      |
   | D1 & D2            |    D3     |                                |

   Since the property item which is either the stateless (B1) or the
   stateful (B2) only decides the relationship between the two types of
   addresses for source hosts, the sub-solutions to their source address

Xu, et al.                Expires May 14 2019                 [Page 7]
Internet-Draft             SAVI Transition               November 2018

   validation depend on property group A. Similarly, sub-solutions to
   source address validation for property items C1 and C2 are all
   decided by property group A as well. However, if it is the situation
   where multi-hosts share an IP address by the multiplexing upper port,
   SAVI Switch should bind its port-range together along with group A
   required, Property group D needs save the NAT-Table for traceback.

       Table III. Solutions of Source address validation for property

Xu, et al.                Expires May 4 2019                 [Page 8]
Internet-Draft             SAVI Transition               November 2018

   |Index | Combination  |Transition Scenario |Solutions in SAVI Swi.|
   |      |   A1-B1-     | Dual-Stack with    | <IPv6, MAC, Switch-  |
   | 1    |   C1/C2/-    | stateless scenario | Port, IPv4>          |
   |      |  (D1/D2/D3)  | in Public 4over6   |                      |
   |      |   A1-B1-     | Dual-Stack with    | <IPv6, MAC, Switch-  |
   | 2    |   C3/C4/-    | stateless scenario | Port, IPv4, Port-    |
   |      |  (D1/D2/D3)  | in Light-Weighted  | Range>               |
   |      |              | Public 4over6      |                      |
   |      |   A1-B2-     | DS-Lite;           | <IPv6, MAC, Switch-  |
   | 3    |   C1/C2/-    | Dual-Stack with    | Port>  Concentrator  |
   |      |  (D1/D2/D3)  | stateful scenario  | verifies relationship|
   |      |              | in Public 4over6   | of <IPv6,IPv4>       |
   |      |   A1-B2-     | Dual-Stack with    | <IPv6, MAC, Switch-  |
   | 4    |   C3/C4/-    | stateful scenario  | Port>  Concentrator  |
   |      |  (D1/D2/D3)  | in Light-Weighted  | verifies relationship|
   |      |              | Public 4over6      | of <IPv6,IPv4,port-R>|
   |      |  A2-B1-      | 4RD;               | <IPv6, MAC, Switch-  |
   | 5    |  C1/C2-      | IPv4-only with     | Port,(Port-Range)>   |
   |      | (D1/D2/D3)   | stateless scenario |                      |
   |      |              | in public 4over6   |                      |
   |      |  A2-B1-      | A+P;               | <IPv6, MAC, Switch-  |
   | 6    |  C3/C4-      | IPv4-only with     | Port,(Port-Range)>   |
   |      | (D1/D2/D3)   | stateless scenario |                      |
   |      |              | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |
   |      |  A2-B2-      | IPv4-only with     | <IPv6, MAC, Switch-  |
   | 7    |  C1/C2-      | stateful scenario  | Port,(Port-Range)>   |
   |      | (D1/D2/D3)   | in public 4over6   |                      |
   |      |  A2-B2-      | IPv4-only with     | <IPv6, MAC, Switch-  |
   | 8    |  C3/C4-      | stateful scenario  | Port,(Port-Range)>   |
   |      | (D1/D2/D3)   | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |
   | 9    |  A3-B1       | 6RD;               |<IPv6,MAC,Switch-port>|
   | 10   | A3-B2        |                    | same with row index 9|

Xu, et al.                Expires May 4 2019                 [Page 9]
Internet-Draft             SAVI Transition               November 2018

   We also consider the solution to the source address validation for
   property combinations. In table III, the notation ''-'' in column of
   ''Combination'' means the relation of union, while the slash notation
   indicates single choice from multi-option, and the bracket states the
   optional relationship. Taking the combination A1-B1-C1/C2-(D1/D2/D3)
   as an example, it depicts that property item A1 combines with B1, and
   then they as a whole unite with either C1 or C2. This combination
   could be further preceded with any property items in group D.

   Even though we can bind two kinds of address and other information
   together in dual-stack network, for the consistent reason and
   considering the performance of SAVI Switch in parsing DHCPv4(6)
   messages from the upper tunnel protocol in scenarios which involved
   with A2 and A3, we turn to an alternative approach where the switch
   only binds IPv4(6) with other information. And tunnel terminal snoops
   IPv4/IPv6 address assignment protocols in order to save the records
   of IPv4-IPv6 (stateful), and verifies it for each packet either in
   stateless or stateful scenarios, as row index from 1 to 4.

3.3. Solutions to IP source address traceback

   The traceback means that system can locate the senders of the
   suspicious packets original from. To achieve this goal, IP source
   address in every packet should be authentic and trustful. This can be
   implemented by authenticating the sender in SAVI Switch and recording
   the IP mapping-table in each NAT device. Finally, administrators can
   track down the sender by following the path from the packet receiver
   to the sender. Table IV presents the method of traceback for
   individual property.

   In the stateless scenarios, a very tough problem exists for the
   traceback; that is, it's hard to locate the device of tunnel
   initiator from the side of the tunnel terminal because the interface
   address of the tunnel is packets' source address related to IPv6(4)
   address, rather than the tunnel-device's address. It will become much
   easier if the tunnel terminal has the mapping-relationship with the
   tunnel's interface address and the tunnel-device's address. Thus, we
   have the approach to extending IP header of the tunnel protocol to
   include the tunnel-device's address, and tunnel terminal saves this

   As to the question of how to extend IP header to achieve this goal,
   it is a relatively minor issue which can be realized by creating a
   new option in IPv6 destination header or utilizing rarely-used fields
   in IPv4 header. We have to admit that we do sacrifice some cost for
   traceback in this situation, but as a comprehensive research we still
   present out and let the network authorities to make their choices.

Xu, et al.                Expires May 4 2019                [Page 10]
Internet-Draft             SAVI Transition               November 2018

   Besides, another key issue is the SAVI Management Database (SMD)
   which collects information from all SAVI Switches in domain by SNMP
   protocol, including the binding-status-table and other important data.
   Therefore, administrators could directly lock the source-host by
   consulting this database with its IP source address or other
   distinctive conditions.

        Table IV. Sub-Solutions to traceback for single property
   |   Value   | Measurements                                        |
   |    A1     | Queried IPv4 address->deduce(stateless) or look up  |
   |           | table(stateful)->IPv6->locate                       |
   |    A2     | Depends on group B                                  |
   +-----------+                                                     |
   |    A3     |                                                     |
   |    B1     | Extend IP header to include tunnel initiator's      |
   |           | address, and tunnel terminal saves relationship of  |
   |           | <interface address of tunnel,device IP address of   |
   |           | tunnel device>                                      |
   |    B2     | IPv6(4) address is obtained by looking up IPv4-IPv6 |
   |           | mapping-table in 4over6 terminal                    |
   |    C1     | Depends on A                                        |
   |    C2     | Depends on A                                        |
   |    C3     | Take port number with IPv4 address as condition to  |
   |           | query 'Binding Status Table' in SAVI Switch         |
   |    C4     | Same with C3                                        |
   |    D      | Take queried IPv4 address as condition to retrieve  |
   |           | original IPv4 address by looking up NAT table       |

      Table V. Solutions to IP traceback for property combinations

Xu, et al.                Expires May 4 2019                [Page 11]
Internet-Draft             SAVI Transition               November 2018

   |Index | Combination  |   4over6 Plans     | Track Path           |
   |      |   A1-B1-     | Dual-Stack with    | Queried v4->(Original|
   | 1    |   C1/C2/-    | stateless scenario | v4 (via D2))->v6 (via|
   |      |  (D1/D2/D3)  | in Public 4over6   | deduce)-> lock sender|
   |      |   A1-B1-     | Dual-Stack with    | same with row index 1|
   | 2    |   C3/C4/-    | stateless scenario |                      |
   |      |  (D1/D2/D3)  | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |
   |      |   A1-B2-     | DS-Lite;           | Queried v4->(Original|
   | 3    |   C1/C2/-    | Dual-Stack with    | v4 (via D2))->v6 (via|
   |      |  (D1/D2/D3)  | stateful scenario  | look table)->lock    |
   |      |              | in Public 4over6   | sender               |
   |      |   A1-B2-     | Dual-Stack with    | same with row index 3|
   | 4    |   C3/C4/-    | stateful scenario  |                      |
   |      |  (D1/D2/D3)  | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |
   |      |  A2-B1-      | 4RD;               | Queried v4->(Original|
   | 5    |  C1/C2-      | IPv4-only with     | v4 (via D2))->v6 (via|
   |      | (D1/D2/D3)   | stateless scenario | deduce)-> lock       |
   |      |              | in public 4over6   | tunnel initiator->   |
   |      |              |                    | (original v4(via D1))|
   |      |              |                    | ->locate sender      |
   |      |  A2-B1-      | A+P;               | same with row index 5|
   | 6    |  C3/C4-      | IPv4-only with     |                      |
   |      | (D1/D2/D3)   | stateless scenario |                      |
   |      |              | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |
   |      |  A2-B2-      | IPv4-only with     | Queried v4->(Original|
   | 7    |  C1/C2-      | stateful scenario  | v4 (via D2))->v6 (via|
   |      | (D1/D2/D3)   | in public 4over6   | look table)->lock->  |
   |      |              |                    | tunnel initiator->   |
   |      |              |                    | (original v4(via D1))|
   |      |              |                    | ->locate sender      |
   |      |  A2-B2-      | IPv4-only with     | same with row index 7|
   | 8    |  C3/C4-      | stateful scenario  |                      |
   |      | (D1/D2/D3)   | in Light-Weighted  |                      |
   |      |              | Public 4over6      |                      |

Xu, et al.                Expires May 4 2019                [Page 12]
Internet-Draft             SAVI Transition               November 2018

   | 9    |  A3-B1       | 6RD;               |Queried v6->(via      |
   |      |              |                    |deduce->locate tunnel |
   |      |              |                    |initiator (via look    |
   |      |              |                    |table)->locate sender |
   | 10   | A3-B2        |                    | same with row index 9|

   Table 5 illustrates the fully track-path for property combinations.
   Taking the first row in this table as an example, we try to locate
   the sender of a suspicious packet in the destination network. The
   first step is to look up the NAT mapping-table to retrieve the
   original IPv4 address if there exists an NAT device. Since it's the
   dual-stack and stateless scenario, the source-host uses its own IPv6
   as the tunnel interface's address to forward its own IPv4 packets;
   this IPv6 address can be deduced from its pre-translated IPv4 address.
   Finally, the sender will be located by consulting SMD based on its
   IPv6 address.

4. Framework verification

   In this section, we apply our framework to some famous previous
   mentioned schemes to verify its correctness.

4.1. Public 4over6

   Packets with public IPv4 addresses over IPv6 networks, namely Public
   4over6, are the mechanism for bi-directional IPv4 communication
   between IPv4 Internet and IPv4 networks which are both sited in IPv6
   access network.

   Fig.1 shows the general scenario in Public 4over6 plans. The 4over6
   Concentrator acts as a tunnel end-point receiving packets from 4over6
   tunnel initiators and forwarding them to IPv4 Internet, while the CPE
   (Customer Premises Equipment) device performs as a tunnel broker for
   the solo-stack 4over6 host on the border of the local IPv4 network.
   Another type of 4over6 hosts in IPv6 network gets their IPv4
   addresses and accesses IPv4 Internet by using their own IPv6
   addresses as a tunnel broker, thus, we classify it into the dual-
   stack category. There are also two kinds of relationship between the
   IPv4 address belongs to 4over6 host and the IPv6 address belongs to
   its tunnel interface, that is, stateful and the stateless. The
   difference between them is that the stateless mode takes IPv4-
   embedded IPv6 as the tunnel initiator's address, on contrary, the
   stateful means IPv4 address for the 4over6 host and the IPv6 address

Xu, et al.                Expires May 4 2019                [Page 13]
Internet-Draft             SAVI Transition               November 2018

   for the tunnel initiator have no relation with each other, so that
   the 4over6 Concentrator needs to save the mapping relationship to
   provide correct forwarding. Two types of initiators with two address
   relationships, there are total four scenarios: solo-stack with the
   stateless (A2-B1-C2), dual-stack with the stateful (A1-B2-C2), solo-
   stack with the stateful (A2-B2-C2) and dual-stack with the stateless
   (A1-B1-C2). Their source addresses and traceback solutions can be
   referred to previous tables.

                       |    IPv6 ISP Network     |
                    +------+                     |
                    |host: |                     |
                    |initi-|                     |
                    |ator  |=================+-------+   +-----------+
                    +------+                 |4over6 |   |   IPv4    |
                       |      IPv4-in-IPv6   |Concen-|---| Internet  |
      +----------+  +------+                 |trator |   |           |
      |local IPv4|--|CPE:  |=================+-------+   +-----------+
      | network  |  |initi-|                     |
      +----------+  |ator  |                     |
                    +------+                     |
                       |                         |

         Figure 1 The overview of Public 4over6 transition scenario

4.2. 6RD

   6RD (IPv6 Rapid Deployment on IPv4 Infrastructures) is a typical
   6over4 tunnel transition scheme. The 6rd ''Customer Edge'' (CE) router
   functions as a tunnel broker to encapsulate and forward packets for
   the source-host on the border of the local IPv6 network, while 6rd
   Border Relay (BR) router located at the SP premises acts as a tunnel
   terminal to de-capsulate and relays packets to IPv6 Internet. It
   belongs to the stateless scenario since the IPv6 address of the
   source-host and IPv4 address of CE WAN interface can be conducted to
   each other. Therefore, 6RD belongs to the combination of A3-B1.

4.3. DS-Lite

   Dual-Stack lite is a 4over6 transition plan. NAT function is
   performed in CGN (Carrier Grade NAT) device to provide the
   translation function from the private to the public IPv4 address. We
   treat DS-Lite as the property combination of the Dual-Stack, stateful

Xu, et al.                Expires May 4 2019                [Page 14]
Internet-Draft             SAVI Transition               November 2018

   and private IPv4 address and NAT in the destination network, that is,
   A1-B2-C1-D2. According to the framework, the access SAVI Switch for
   CPE (home gateway) should bind its IPv6, MAC address and the uplink
   port together. Since the NAT and tunnel function fulfilled by CGN
   device and their records are in a same table, the trace path follows
   the direction from the queried IPv4 address to tunnel property by
   referring to the NAT record. Then it locates CPE device in user's
   household by following the tunnel information.

4.4. 4RD

   IPv4 Residual Deployment (4RD) is a 4over6 mechanism to facilitate
   IPv4 residual deployment across IPv6 networks of ISP's. It can be
   treat as the combination of A2-B1-C2. More information is the
   Softwire workgroup has decided to put 4RD and MAP-T[14] on
   experimental track and MAP-E[15] on standards track.

4.5. A+P

   The address-plus-port (A+P) approach also is 4over6 plan which
   advocated by the France Telecom, Nokia and other companies for
   resolving the issue of IPv4 address shortage. A+P treats some bits
   from the port number in the TCP/UDP header as additional end-point
   identifiers to extend the address field. A+P is an architecture which
   combines MAP-E, MAP-T and 4RD. Although proposer described as a
   stateful version but the IETF still put it into a stateless solution,
   thus, we treat it as a property combination of A2-B1-C3-D1.

4.6. IVI

   IVI is a typical translation transition solution which provides
   bilateral access from both pure single stack sides. The service
   providers reserve a piece of range IPv4 address (IVI4) so that they
   can map them with a special range of IPv6 address (IVI6) as the
   ration of 1:1, then the IVI translator keeps the communication
   correctly. Another ration of 1(IPv4):N(IPv6) was called DIVI[16]
   which implemented by splitting port only supports IPv6 initiated
   communication. But no matter which type, the anti-spoofing measure is
   same with pure stack which follows the SAVI's specification, and
   keeping the stateless mapping records in order to trackback.

5. Framework implementation

   The framework implementation is actually quite simple, which has been
   illustrated by table VI. We categorized the modules into four types
   and each type has its own deployment position. There are two special
   occasions we must address. One is that, when a source-host is in an

Xu, et al.                Expires May 4 2019                [Page 15]
Internet-Draft             SAVI Transition               November 2018

   IPv4 with port-sharing network, the binding module in SAVI Switch
   should bind the host's port-range with other data together; and the
   other is that, when the traceback is in tunnel stateless scenarios,
   we need to extend the tunnel IP header that we mentioned above.

   |Modules | Deployment |   Scenarios        | Module Detail        |
   |Binding |SAVI Switch | IPv4-only(Including|<IPv4, MAC, link-port,|
   |        |            |port-sharing)       |(port-range)>         |
   |        |            |--------------------+----------------------+
   |        |            |IPv6-only&dual-stack|<IPv6, MAC, link-port,|
   |        |            |(port-sharing)      |(port-range)>         |
   |Verific |Tunnel      | Stateless          |Verify the deduction  |
   |ation   |Terminal    |                    |relationship          |
   |        |            |--------------------+----------------------+
   |        |            | Stateful           |Save and verify the   |
   |        |            |                    |mapping relationship  |
   |NAT     |NAT Device& |                    |Record Mapping        |
   |Record  |Translator  |                    |relationship          |
   |Trace-  |Tunnel      | Tunnel initiator extends packets'IP header|
   |back    |Initiator   | to include relationship <Tunnel's interfa |
   |        |            | ce's add.,tunnel initiator device's add.> |
   |        +------------+-------------------------------------------+
   |        |Tunnel      | Tunnel terminal saves the above           |
   |        |Terminal    | relationship for traceback                |

6. Conclusions

   Along with the rapid development of IPv6 networks and the urgent
   demand of inter-communication between IPv4 and IPv6 networks, the
   situation of IPv4/IPv6 transition is inevitable, and lots of
   transition plans are proposed. Simultaneously, the IP spoofing issue
   still bothers network users and administrators, and once it happened,
   it's hard to trace the spoofer. The SAVI proposal, one of the
   excellent solutions to the source address validation, has been
   proposed by IETF SAVI workgroup, which binds host's IP, MAC address
   and uplink-port features in their access switches to achieve the goal
   of preventing nodes attached to the same IP link from spoofing each

Xu, et al.                Expires May 4 2019                [Page 16]
Internet-Draft             SAVI Transition               November 2018

   other's IP addresses. Our goal is to propose a general framework
   which can adapt to all transition especially tunnel plans for IP
   source address validation and traceback with the help of SAVI. In
   this draft, we propose a general framework for anti-spoofing and
   traceback in IPv4/IPv6 transition scenario by extracting the
   essential and mutual properties from various transition schemes. We
   present the sub-solutions or solutions for each property and property
   combinations. Finally, we verify this framework in various transition
   schemes and prove its excellent adaptability and flexibility. We hope
   that it will give more inspiration for more interested researchers,
   work together and finally we can make it happen to achieve the goal
   in practical. In the future, we are planning to establish a platform
   with SDN (Software Defined Networking) mechanism to realize this

7. References

7.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MITSpoofer] MIT Spoofer project

   [SAVI] J.Wu,J.Bi, ''Source Address Validation Improvement
             Framework (SAVI)'', RFC 7039, October 2013.

   [RFC3704] F. Baker,P. Savola, ''Ingress Filtering for Multihomed
             Networks'', RFC3704, March 2004.

   [RFC6219] X.Li, C.Bao etl, ''The China Education and Research Network
             (CERNET) IVI Translation Design and Deployment for the
             IPv4/IPv6 Coexistence and Transition'', RFC6219, May 2011.

   [RFC6333] A.Durand,R.Droms,J.Woodyatt etl, ''Dual-Stack Lite Broadband
             Deploy-ments Following IPv4 Exhaustion'', RFC6333,August

   [4RD] R. Despres, Ed., S. Matsushima, T. Murakami etl, ''IPv4 Residual
             Deployment across IPv6-Service networks (4rd) ISP-NAT's
             made optional draft-despres-intarea-4rd-01'', Internet-Draft,
             March 2011.

   [RFC6346] R. Bush, Ed, ''The Address plus Port (A+P) Approach to the
             IPv4 Address Shortage'', RFC6346, August 2011,

Xu, et al.                Expires May 4 2019                [Page 17]
Internet-Draft             SAVI Transition               November 2018

   [p4over6] Y.Cui, J.Wu, P.Wu, C.Metz, O.Vautrin, Y.Lee, "Public IPv4
             over Access IPv6 Network draft-cui-softwire-host-4over6-06",
             Internet-Draft, July 2011

   [RFC5565] J.Wu, Y.Cui, C.Metz, E.Rosen, ''Softwire Mesh Framework'',
             RFC 5565, June 2009.

   [l4over6] Y.Cui, J.Wu, P.Wu, Q. Sun, C. Xie, C. Zhou, Y.Lee, "
             Lightweight 4over6 in access network draft-cui-softwire-b4-
             translated-ds-lite-04", Internet-Draft, Oct. 2011

   [DHCPv6-map] T. Mrugalski, M. Boucadair, O. Troan,  X. Deng, C. Bao,
             "DHCPv6 Options for Mapping of Address and Port draft-mdt-
             softwire-map-dhcp-option-01'', Internet-Draft, Oct. 2011

8. Acknowledgments

   This document was prepared using

Xu, et al.                Expires May 4 2019                [Page 18]
Internet-Draft             SAVI Transition               November 2018

   Authors' Addresses

   Ke Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing 100084

   Guangwu Hu
   Shenzhen Institute of Information Technology
   School of Cyber-Security, Shenzhen Institute of Information Technology
   Shenzhen,Guangdong 518172

   Fan Shi
   China Telecom
   Beijing Research Institute, China Telecom
   Beijing  100035

   Jun Bi
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084

   Mingwei Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084