SAVI K.Xu, G.Hu, J.Bi, M.Xu Internet Draft Tsinghua Univ. Intended status: Standard Tracks F.Shi Expires: November 2012 China Telecom May 8, 2012 A general SAVI-based source address validation and traceback framework for 4over6 transition scenarios draft-xu-savi-transition-01.txt Abstract Many proposals have been presented for preventing IP spoofing from occurring in network. An outstanding of them is the SAVI (Source Address Validation Improvement) proposal which was advocated by IETF SAVI workgroup for solving this problem from user access switch. SAVI Working Group is developing standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses, and achieve IP source address validation at a finer granularity. However, up to now, to the best of our knowledge, none of them has focused on the scenarios of 4over6 transition, that is, IPv4 packets transit IPv6 network and arrive at other edge IPv4 network(s). With the boom of IPv6 networks, this issue becomes more and more urgent. In addition, since 4over6 plans are plenty and various, one solution cannot meet all requirements of these plans. This document describes a framework of IP source address validation and traceback for 4over6 transition scenarios, which extract out the essential and mutual properties from these plans and form corresponding sub-solution for each property. When one 4over6 plan is combined by some of them, the solution of IP source address validation and traceback for this plan are directly comprised of the combination of corresponding sub- solution. Thus, the most exciting advantage of this framework is that it is a once for all solution no matter how 4over6 plans changes. 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 http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Xu, et al. Expires November 8, 2012 [Page 1] Internet-Draft SAVI Transition May 2012 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 8, 2012. Copyright Notice Copyright (c) 2012 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. 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............................. 5 3.Framework description......................................... 5 3.1.Goals and considerations of this framework............... 5 3.2.Property extraction...................................... 5 3.3.Measurements for IP source address validation............ 7 3.4.Measurements for IP source address traceback............. 9 4.Framework verification....................................... 12 4.1.Public 4over6 .......................................... 12 4.2.Lightweight public 4over6 .............................. 14 4.3.DS-Lite ................................................ 14 Xu, et al. Expires November 8 2012 [Page 2] Internet-Draft SAVI Transition May 2012 4.4.4RD .................................................... 15 4.5.A+P .................................................... 15 5.Conclusions ................................................. 15 6.References .................................................. 16 6.1.Normative References.................................... 16 7.Acknowledgments ............................................. 17 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. 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 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 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. In other words, two kinds of networks will be coexistence for a 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 Xu, et al. Expires November 8 2012 [Page 3] Internet-Draft SAVI Transition May 2012 is also known as "softwires"[RFC5565] which provides packet transit service from one edge of single-protocol network to other. Even though there are many mature and practical solutions for validating IP source address in single-protocol networks. Unfortunately, to the best of our knowledge, solutions for IP source address validation and traceback in the scenario of IPv4/IPv6 coexistence are not been researched yet. Besides, since the transition plans are plenty and various, it's not practical to proposal a source address validation scheme for each transition plan, and it's not possible to find a solution to satisfy all requirements of these plans either. So the transition issue becomes more and more urgent, the matter of source address verification in this scenario is also important as well. With the rapid development of IPv6 network, we have reason to believe that IPv6 Internet will become the solo backbone eventually. But before this, the situation of IPv4 packets transit IPv6 network and arrive at other edge IPv4 network(s), namely 4over6 transition, will exists for a long period. +-------------------------+ | 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 Figure 1 shows a class 4over6 transition scenario, which is described in Public 4over6 plans. The 4over6 Concentrator acts tunnel end-point receives packets from 4over6 tunnel initiators and forwards them into IPv4 Internet, while the CPE (Customer Premises Equipment) performs as a tunnel broker for solo-stack 4over6 host. The 4over6 host in the IPv6 network is tunnel initiator for itself. This document focuses on how to setup a general SAVI-based framework to validate and traceback IP source address in 4over6 transition scenarios. Xu, et al. Expires November 8 2012 [Page 4] Internet-Draft SAVI Transition May 2012 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Framework description In this section, we will describe this framework in detail. But ahead of this, introducing design goals and considerations will benefit for readers to well-known our minds. 3.1. Goals and considerations of this framework Goal 1. This framework focuses on the 4over6 transition scenarios with tunneling mechanism. Goal 2. This framework should have the ability of source address verification, and also the traceback function for given address. Goal 3. This framework could adapt all of 4over6 transition plans, no matter how much scenarios change. To keep packets carry with trusted IP source address, it should let the packets comes from the authorized user who is the owner of packet's source address, and prevent spoofed packets from forwarding. Naturally, deploying SAVI Switch into users' access subnet to keep all of hosts' trustiness is one of straightforward ideas. Furthermore, it has to record mapping table in each place where source address could be changed (e.g. NAT). Such ideas would directly facilitate the implementation of traceback function, and the only thing that system needs to do is reverse trace based on the given IP source address. Another basic idea for fulfilling the third goal is extract essential and mutual properties from these transition plans and form corresponding sub-solution for each property. When one 4over6 transition plan is combined by different properties, the solution of IP source address validation and traceback for this plan naturally is the combination of the corresponding sub-solution. 3.2. Property extraction Requiring one framework to adapt all 4over6 transition plans is difficult. After investigated almost all of these plans, we found that there existing basic common properties in them. Therefore, if we can extract these properties from these plans and restore them by Xu, et al. Expires November 8 2012 [Page 5] Internet-Draft SAVI Transition May 2012 reassembling required properties afterward, this would provide the possibility for establishing such framework. Actually, this has been achieved based on three property extraction rules: 1) it only extract those common and essential elements, and don't care the irrelevant details; 2) Each element shouldn't be decomposed any further, in other words, each element should be atomic and unique; 3) It should have the ability of plans-reconstruction by reassembling relevant elements. The result of property extraction is illustrated as Table I. Table I. Properties in 4over6 plans +--------------------+-----------+-------------------------+------+ | Property Group |Group Code | Property Name | Value| +--------------------+-----------+-------------------------+------+ |Protocol stacks of | A | Dual-Stack | A1 | |4over6 host | |-------------------------+------+ | | | IPv4 only | A2 | +--------------------+-----------+-------------------------+------+ |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 | +-----------------------------------------------------------------+ |Positions of NAT | D | Near to CPE | D1 | |device | +-------------------------+------+ | | | Near to CGN AFTR | D2 | | | +-------------------------+------+ | | | D1 & D2 | D3 | +-----------------------------------------------------------------+ CGN: Carrier-grade NAT AFTR: Address Family Transition Router We summarized these properties into four categories with eleven items. Group B indicates the relationship between IPv4 and IPv6 address in 4over6 host, stateless means they are related since they can be deduced by each other, otherwise, it's stateful. Property C3 and C4 Xu, et al. Expires November 8 2012 [Page 6] Internet-Draft SAVI Transition May 2012 states multi-4over6 hosts share an IPv4 address by splitting port- range. The description for NAT position belongs to group D. Property D1, D2 and D3 declares the NAT devices in the position of border of user local network, ISP's network in IPv4 Internet, and both sides, respectively. 3.3. Measurements for IP source address validation Table II. Measurements of Source address validation for each property +--------------------+-----------+--------------------------------+ | Property Name | Value | Measurements in SAVI Switch | +--------------------+-----------+--------------------------------+ | Dual-Stack | A1 | | +--------------------+-----------+--------------------------------+ | IPv4 only | A2 | | +--------------------+-----------+--------------------------------+ | Stateless | B1 | Depends on property A | +--------------------+-----------+--------------------------------+ | Stateful | B2 | Depends on property A | +--------------------+-----------+--------------------------------+ | Private | C1 | Depends on property A | +--------------------+-----------+--------------------------------+ | Public | C2 | Depends on property A | +--------------------+-----------+--------------------------------+ | 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 | Recording the NAT-Table | +--------------------+-----------| | | D1 & D2 | D3 | | +--------------------+-----------+--------------------------------+ As we mentioned, the goal of IP source address validation is to keep packets bring with trustful IP source addresses, and this is also the basis of traceback and other applications. SAVI Switch binds , the triad-relationship of end-host to achieve this goal, but till now, it's only applicable for single-stack network (IPv4 or IPv6), which means SAVI Switch needs to be improved to adapt dual- stack and other complex scenarios. Although we can enumerate all possibilities of property combinations, and consider how to improve Xu, et al. Expires November 8 2012 [Page 7] Internet-Draft SAVI Transition May 2012 it to adapt to each scenario, it's not a smart choice because of its inflexibility and violation with the third goal. In contrast, we list out the measurements of source address validation for each property, as illustrated in Table II. We hope to obtain source address validation solution for each 4over6 plan by reassembling corresponding measurements. Table III. Measurements of Source address validation for property combinations +------+--------------+--------------------+----------------------+ |Index | Combination | 4over6 Plans | Measurements in SAVI | +---------------------+--------------------+----------------------+ | | A1-B1- | Dual-Stack with | | | | (D1/D2/D3) | in Public 4over6 | | +---------------------+--------------------+----------------------+ | | A1-B1- | Dual-Stack with | | | | | Public 4over6 | | +---------------------+--------------------+----------------------+ | | A1-B2- | Dual-Stack with | Concentrator | | | (D1/D2/D3) | in Public 4over6 | verifies relationship| | | | | of | +---------------------+--------------------+----------------------+ | | A1-B2- | Dual-Stack with | Concentrator | | | (D1/D2/D3) | in Light-Weighted | verifies relationship| | | | Public 4over6 | of | +---------------------+--------------------+----------------------+ | | A2-(B1/B2)- | DS-Lite; 4RD; A+P; | | | | -(D1/D2/D3) | in Public 4over6; | | | | | Solo-Stack scenario| | | | | in Light-Weighted | | | | | Public 4over6 | | +---------------------+--------------------+----------------------+ As we explain previously, property stateless or stateful only decides the relationship between IPv4 and IPv6 address for 4over6 hosts. Hence, they have no particular treatment and their measurements Xu, et al. Expires November 8 2012 [Page 8] Internet-Draft SAVI Transition May 2012 depend on property A1 or A2. Property group C manifests the status of IPv4 address, no matter the address is private or public, measurements for them are all decided by property group A (C1 and C2). However, if it's the situation of multi-hosts shares an IP address by multiplexing its port, measurements should bind the address along with its port-range as well, e.g. C3,C4. Property group D needs no extra considerations except recording the NAT-Table for traceback function. Table III list out measurements of source address validation for property combinations, in the column of ''Combination'', the notation ''- '' means relation-union, and the slash notation means choose anyone of them, while the bracket notation states optional relationship. Take the combination of A1-B1-C1/C2-(D1/D2/D3) as example, it indicates that property item A1 combine with B1 firstly, and then they union with C1 or C2 either, following result can be proceed in further with anyone of property in group D, but it's optional rather than compulsive. There have extra two explains about Table III. In the scenario of dual-stack and stateful (row-index 3, 4), which means end-host has both IPv4 and IPv6 address and they are unrelated, we did not require SAVI Switch to bind IPv4 address with other information, even though how much we want to do this for reducing the verification process in 4over6 Concentrator. However, considering the performance of SAVI Switch and the fact of request a Layer2.5 switch to parse DHCPv4 messages from upper tunnel protocol is inappropriate, the alternative approach is forcing 4over6 Concentrator to verify the mapping- relationship. Another point we want to point out is the last row of this table, SAVI Switch in IPv4 network only has to bind illustrated relationship without any improvement. 3.4. Measurements for IP source address traceback Traceback function means administrator can locate the original senders of suspicious packets. To achieve this goal, IP source address in every packet should be authentic and trustful. This can be implemented by authenticating sender in SAVI Switch and recording IP mapping-table in each NAT place, and finally, administrator can find out the sender by tracing the reverse path from the receiver to the sender. Table IV presents the individual measurement in detail for each property. Xu, et al. Expires November 8 2012 [Page 9] Internet-Draft SAVI Transition May 2012 Table IV. Measurements of Traceback for each property +-----------+-----------------------------------------------------+ | Value | Measurements | +-----------+-----------------------------------------------------+ | A1 | Queried IPv4 address->deduce(stateless) or look up | | | table(stateful)->IPv6->locate | +-----------+-----------------------------------------------------+ | A2 | Only with B1 together: extend IPv6 header to include| | | IPv6 address of CPE, and Concentrator saves the map-| | | ping-relatioship of tunnel interface and CPE's IPv6 | +-----------+-----------------------------------------------------+ | B1 | IPv6 address is deduced by queried IPv4 address. | +-----------+-----------------------------------------------------+ | B2 | IPv6 address is obtained from IPv4-IPv6 mapping- | | | table in 4over6 Concentrator | +-----------+-----------------------------------------------------+ | 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 | +-----------+-----------------------------------------------------+ When property A2 combines with property B1, there is a special treatment for this condition. In this scenario, since tunnel initiator's address is the 4over6 host's IPv4 related IPv6 address, rather than CPE's IPv6 address. Therefore, there exists a very tough problem for traceback, that is, how to locate CPE device in 4over6 Concentrator even if we already have the corresponding IPv6 address for a given IPv4 address. It will become easy if 4over6 Concentrator has the relationship of CPE's and tunnel initiator's address. Once the corresponding IPv6 address is obtained either by deduce or look up mapping-table in NAT for a given IPv4 address, we can locate CPE device by searching the mapping-table. We will give the detail about it in next section. As to the question of how to extend IPv6 header to achieve this goal, that's a minor issue which we will not discuss it here in detail. Xu, et al. Expires November 8 2012 [Page 10] Internet-Draft SAVI Transition May 2012 Actually, this can be realized by creating a new option in IPv6 destination header. Table V. Trace-Paths for property combinations +------+--------------+--------------------+----------------------+ |Index | Combination | 4over6 Plans | Track Path | +---------------------+--------------------+----------------------+ | | A1-B1- | Dual-Stack with | Queried IPv4 -> (pre-| | 1 | C1/C2/- | stateless scenario | translate IPv4(via D2| | | (D1/D2/D3) | in Public 4over6 | )-> IPv6(via deduce) | | | | | -> locate sender | +---------------------+--------------------+----------------------+ | | A1-B1- | Dual-Stack with | | | 2 | C3/C4/- | stateless scenario | Equal to row index 1 | | | (D1/D2/D3) | in Light-Weighted | | | | | Public 4over6 | | +---------------------+--------------------+----------------------+ | | A1-B2- | Dual-Stack with | Queried IPv4 -> (pre-| | 3 | C1/C2/- | stateful scenario | translate IPv4(via D2| | | (D1/D2/D3) | in Public 4over6 | )-> IPv6(via look up | | | | | table)->locate sender| +---------------------+--------------------+----------------------+ | | A1-B2- | Dual-Stack with | | | 4 | C3/C4/- | stateful scenario | Equal to row index 3 | | | (D1/D2/D3) | in Light-Weighted | | | | | Public 4over6 | | +---------------------+--------------------+----------------------+ | | A2-(B1/B2)- | DS-Lite; 4RD; A+P; | Queried IPv4 -> (pre-| | 5 |(C1/C2/C3/C4) | Solo-Stack scenario| translate IPv4(via D2| | | -(D1/D2/D3) | in Public 4over6; | )-> IPv6(via look up | | | | Solo-Stack scenario| table)->locate CPE ->| | | | in Light-Weighted | (pre-translate IPv4 | | | | Public 4over6 | (via D1))->locate | +---------------------+--------------------+----------------------+ In addition, another very key issue is that there is a SAVI management database which collects information from all of SAVI Switches in intra-domain by SNMP protocol, including binding status table and other important data. Thus, by consulting this database with a given IP address, we can learn that the owner of this address uplinks to which port and which SAVI Switch. With the database's help, locating a host from its IP address is pretty easy. Xu, et al. Expires November 8 2012 [Page 11] Internet-Draft SAVI Transition May 2012 Table V illustrates the trace-paths for property combinations. Taking first row in the table as example, we try to locate the sender of a packet with queried IPv4 source address in IPv4 Internet. If there has a CGN device in the boundary of IPv4 Internet and IPv6 network, looking up the NAT mapping-table to retrieve the pre-translation IPv4 address is the first step. Since it's the dual-stack and stateless scenario, the corresponding IPv6 address can be deduced based on IPv6 and IPv4 address conversion rule, and 4over6 host uses its own IPv6 address as tunnel initiator to forward its IPv4 packets to 4over6 Concentrator. Finally, the sender will be located by consulting SAVI management database based on sender's IPv6 address. 4. Framework verification In this section, we will apply this framework into some famous 4over6 transition plans to verify its correctness, such as DS-Lite, Public 4over6, Light-Weighted Public 4over6[l4over6], 4RD and A+P etc. 4.1. Public 4over6 Packet with public IPv4 address over access IPv6 network, namely public 4over6, is a mechanism for bidirectional IPv4 communication between IPv4 Internet and end-hosts or IPv4 networks sited in IPv6 access network. This mechanism follows the softwire hub and spoke model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. Fig.1 shows the general working scenarios of Public 4over6. There are two types of tunnel initiator: host and CPE initiator. Part of 4over6 hosts in IPv6 network use their own IPv6 address to establish tunnel with 4over6 Concentrator and forward IPv4 packets for themself, while other 4over6 hosts in local IPv4 network need CPE to be their initiator to encapsulate and forward their IPv4 packets. Public 4over6 also has stateful and stateless two address forms. The difference among them is that the stateless mode takes IPv4-embedded IPv6 as tunnel initiator's address, while the stateful mode means the two addresses, IPv4 address for 4over6 host and IPv6 address for tunnel initiator, have no relationship with each other, so that 4over6 Concentrator needs to save the mapping relation to provide correct forwarding. Two types of initiators with two address forms, that are four scenarios, we analyze them as follows. Xu, et al. Expires November 8 2012 [Page 12] Internet-Draft SAVI Transition May 2012 Scenario 1: Solo-Stack with stateless (A2-B1-C2) The 4over6 host in stateless mode has only IPv4 address, while CPE in the border of local IPv4 network plays the role of tunnel initiator and protocol proxy. When CPE receives a DHCPv4 request from local 4over6 host, it will convert it to DHCPv6 request and forward it to DHCPv6 server in IPv6 access network [DHCPv6-map], afterwards, the server then fetches an IPv4 address from IPv4 address pool randomly and produce a DHCPv6 reply which follows the address conversion rules, then finally, CPE will equip this IPv6 address and parse IPv4 address from it for producing DHCPv4 to reply to the requestor. Otherwise, when CPE receives an outbound data packet, it will take the mapped IPv6 of IPv4 source address in this packet as tunnel initiator's address and encapsulate them into tunnel (e.g. GRE), 4over6 Concentrator receives and decapsulates packets from tunnels and forward them to next-hop. SAVI Switch should to snoop the DHCPv4/PCP protocols interaction and bind the relationship of , which mentioned in Table III with combination of A2-B1-C2. Translating the queried IPv4 address to IPv6 address by address conversion rules, tracking the CPE device by looking up the address mapping-table of CPE and tunnel initiator in 4over6 Concentrator, consulting SAVI management database and locating the sender are the three phrases of traceback, respectively. Scenario 2: Dual-Stack with stateful (A1-B2-C2) In order to access both IPv4 and IPv6 resources, this type of 4over6 hosts own IPv4 and IPv4 unrelated IPv6 addresses, IPv6 address is allocated by traditional way such as DHCPv6 or SLAAC in IPv6 network, however, IPv4 address is assigned by DHCPv4 server in IPv4 Internet with the way of DHCPv4 over IPv6. For purpose of anti-spoofing in users access subnet, naturally, we maybe consider SAVI Switches snoop address assignation protocols, i.e. DHCPv6, PCP, and bind the relationship of for each 4over6 host. However, given the ability of parse DHCPv4 protocol from upper layer in a layer2.5 switch, we turn to 4over6 Concentrator for help by verifying the address mapping relationship instead of bind two kinds of address together in access SAVI Switch. Xu, et al. Expires November 8 2012 [Page 13] Internet-Draft SAVI Transition May 2012 Finding the initiator's IPv6 address for suspicious IPv4 address in 4over6 Concentrator and locating the sender directly are the two steps of tracking sender. Scenario 3: Solo-Stack with stateful (A2-B2-C2) In this scenario, 4over6 host in IPv4 network only owns a public IPv4 address with the way of DHCPv4 overt IPv6, and CPE uses its own IPv6 address as tunnel initiator for forwarding packets from these hosts. Thus, there is no need to extend IPv6 header for saves the mapping relationship between CPE and initiator's IPv6 address in 4over6 Concentrator to. Except the step of look up mapping-table for locating CPE is reduced, the rest of parts in traceback function are same as scenario one, as well as the binding processes. Scenario 4: Dual-stack with stateless (A1-B1-C2) This type of 4over6 host has both IPv4 and IPv6 addresses, and they are related. These hosts take their own IPv6 addresses as tunnel initiator for forwarding IPv4 packets from themself. Their SAVI Switches bind the relationship of for anti- spoofing. The slight difference in trace-back between scenario 2 and this scenario is the way of obtain related IPv6 address of queried IPv4, which is finished via deduce, rather than search the mapping- table in concentrator. 4.2. Lightweight public 4over6 Compared with Public 4over6 plan, there is a slight change between these two plans in the form of IPv4 address. Briefly, lightweight public 4over6 mitigates IPv4 address exhaustion by sharing public IPv4 addresses amongst hosts with different port range, and this can be achieved by extending DHCPv4 and PCP protocol, while hosts in public 4over6 own their unique public IPv4 address. The two transition plans are similar except replace C2 with C3 property for each scenario. Validating and traceback process could be referred to Table III and V. 4.3. DS-Lite Dual-Stack lite also is a transition plan which encapsulates IPv4 packets over IPv6 access network. NAT function is performed in CGN device to provide IPv4 address translation from private to public. It Xu, et al. Expires November 8 2012 [Page 14] Internet-Draft SAVI Transition May 2012 allows single public IPv4 address to be shared by multi-requestor to increase port utilization. We treat DS-Lite is the property combination of Dual-Stack, stateful, private IPv4 address and NAT in CGN, that is A1-B2-C1-D2. According to the rules, the access SAVI Switch of CPE (home gateway) should bind its IPv6, MAC address and uplink port together. Since the NAT and tunnel information are all in the NAT-Table together, the trace path should follow the direction from queried IPv4 address to tunnel- id by looking up NAT-Table, and then locate CPE device in user's household by following the tunnel information. 4.4. 4RD IPv4 Residual Deployment (4RD) is a mechanism to facilitate IPv4 residual deployment across IPv6 networks of ISP's. It is equal to reverse of 6RD[12] (IPv6 Rapid Deployment on IPv4 Infrastructures, 6over4 plan), scenario 3 in Public 4over6 as well. And it also can be treated as DS-Lite plan without CGN NAT. Thus, measurements for validation and traceback could be referred to previous section. 4.5. A+P Address plus Port(A+P) approach is advocated by France Telecom, Nokia and other companies for the purpose of IPv4 shortage and 4over6 transition. A+P treats some bits from the port number in the TCP/UDP header as additional end-point identifiers to extend the address field. It solves the problem of public IPv4 address shortage for CPE. The PRR (Port Range Router) assigned one public IPv4 address to two CPEs with different port-ranges. CPE plays the role of NAT for allocating private address to local hosts, as well as tunnel initiator for encapsulating IPv4 packets across IPv6 network. A+P can be considered as property combination of A2-B2-C1-D1. Therefore, access SAVI Switch needs to bind IPv4 address and other information which is illustrated in Table V. When we perform traceback function, we need to take IPv4 address along with its port- number to obtain tunnel information in PRR, and then locate CPE based on this information and lock the 4over6 host further. 5. Conclusions Along with the rapid development of IPv6 networks and urgent demand of inter-communication between IPv4 and IPv6 networks, the situation of packets from IPv4 network transit IPv6 Internet (networks) and arrive at other edge IPv4 networks is inevitable, this is also refer Xu, et al. Expires November 8 2012 [Page 15] Internet-Draft SAVI Transition May 2012 to 4over6 transition. Under this circumstance, a lot of 4over6 transition plans for various scenarios are proposed. On the other hand, the stubborn issue of IP source addresses spoofing still bothers network users and administrators, and once it happened, it's hard to trace the spoofer. The SAVI proposal, one of excellent solutions for source address validation, is advocated by IETF SAVI workgroup. SAVI Switch follows SAVI proposal and automatically binds and even other information for access hosts to achieve the goal of prevent nodes attached to the same IP link from spoofing each other's IP addresses. Applying SAVI Switch into 4over6 transition scenarios and proposing a framework adapts all of 4over6 transition plans for source address validation and traceback are our goal. In this document, in the first beginning, we state the background and urgent demands of IPv4-over- IPv6 transition, as well as the necessity of source address validation and traceback. After that, we sort out property groups and items in detail by fully investigating 4over6 transition plans. Moreover, we present the solutions of source address validation and traceback for each property item and even property combination. We give the reasonableness of these solutions and explain how to apply this framework into property combinations. Followed framework verification for most famous 4over6 transition plans proves the excellent adaptability and flexibility in our framework. Although this framework particular highlights the 4over6 transition scenarios and only was verified in most existing 4over6 transition plans, we still emphasize that it is not only suits for 4over6 transition scenarios, but also other transition situations such as 6over4 and even translation transition with only slightly improvement. We hope that it will be improved with more consideration in future for adapting more transition scenarios and achieving the goals of IP source address validation and traceback. 6. References 6.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 http://spoofer.csail.mit.edu/ summary.php. Xu, et al. Expires November 8 2012 [Page 16] Internet-Draft SAVI Transition May 2012 [SAVI] J.Wu,J.Bi etl, ''Source Address Validation Improvement Framework (SAVI) draft-ietf-savi-framework-06'', Internet- Draft, December 2011. [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 2011. [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, [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 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Xu, et al. Expires November 8 2012 [Page 17] Internet-Draft SAVI Transition May 2012 Authors' Addresses Ke Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing, 100084 China Email: xuke@mail.tsinghua.edu.cn Guangwu Hu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 China EMail: hgw09@mails.tsinghua.edu.cn Fan Shi China Telecom Beijing Research Institute, China Telecom Beijing 100035 China EMail: shifan@ctbri.com.cn Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 China Email: xmw@csnet1.cs.tsinghua.edu.cn Xu, et al. Expires November 8 2012 [Page 18]