SAVI K.Xu, G.Hu, J.Bi, M.Xu
Internet Draft Tsinghua Univ.
Intended status: Standard Tracks F.Shi
Expires: May 2013 China Telecom
November 6, 2012
A General Framework of Source Address Validation and Traceback for
IPv4/IPv6 Transition Scenarios
draft-xu-savi-transition-02.txt
Abstract
IP spoofing always is bothering us along with the Internet invention.
With the rapid development of IPv6 next generation Internet, this
issue is more prominent. Existing IP anti-spoofing proposals,
including SAVI(Source Address Validation Improvement) which was
advocated by IETF, only focused on single-stack or simple network
scenarios. To the best of our knowledge, none of them has paid
attention to the IPv4/IPv6 transition scenarios. However, since
transition schemes are plenty and various, one solution cannot meet
all requirements of them. In this draft, we present a SAVI-based
general frame-work 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.
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
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 6, 2013 [Page 1]
Internet-Draft SAVI Transition November 2012
This Internet-Draft will expire on November 6, 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 ........................ 4
3. Framework description .................................... 4
3.1. Property Extraction ................................... 5
3.2. Solutions of IP source address validation ............. 6
3.3. Solutions to IP source address traceback .............. 9
4. Framework verification................................... 12
4.1. Public 4over6 ........................................ 12
4.2. 6RD .................................................. 13
4.3. DS-Lite .............................................. 13
4.4. 4RD .................................................. 14
4.5. A+P .................................................. 14
4.6. IVI .................................................. 14
5. Conclusions ............................................. 14
6. References .............................................. 15
Xu, et al. Expires May 6 2012 [Page 2]
Internet-Draft SAVI Transition November 2012
6.1. Normative References ................................ 15
7. Acknowledgments ......................................... 16
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
is also known as "softwires"[RFC5565] which provides packet transit
service from one edge of single-protocol network to other.
Xu, et al. Expires May 6 2012 [Page 3]
Internet-Draft SAVI Transition November 2012
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 schemes and then forming sub-solutions for each property with
the help of SAVI. Naturally, when one scheme is constituted by
required properties, its source address validation and traceback
solution are combined by corresponding sub-solutions. Thus, our
framework is a once-and-for-all solution no matter how 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.
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 firstly give the threat model and considerations,
and then describe the 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 its source IP
address has been modified. But we believe the network devices (NAT,
Xu, et al. Expires May 6 2012 [Page 4]
Internet-Draft SAVI Transition November 2012
tunnel points, protocol translator etc.) of service providers are
trustful and attacker 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, it is our straight-forward idea 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
It is difficult to require one framework to adapt to all transition
plans. 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. 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
records 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 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 the local network same protocol-stack
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
Xu, et al. Expires May 6 2012 [Page 5]
Internet-Draft SAVI Transition November 2012
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
combination.
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 |
+-----------------------------------------------------------------+
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
Xu, et al. Expires May 6 2012 [Page 6]
Internet-Draft SAVI Transition November 2012
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 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
address-port, SAVI Switch should bind its port-range together along
with group A required, Property group D only needs save the NAT-Table
for traceback.
Table III. Solutions of Source address validation for property
combinations
Xu, et al. Expires May 6 2012 [Page 7]
Internet-Draft SAVI Transition November 2012
+------+--------------+--------------------+----------------------+
|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 6 2012 [Page 8]
Internet-Draft SAVI Transition November 2012
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 scenario 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
mapping-relationship.
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 6 2012 [Page 9]
Internet-Draft SAVI Transition November 2012
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 6 2012 [Page 10]
Internet-Draft SAVI Transition November 2012
+------+--------------+--------------------+----------------------+
|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 6 2012 [Page 11]
Internet-Draft SAVI Transition November 2012
| 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 stateful and the stateless, two kinds of
relationship between IPv4 address of 4over6 host and IPv6 address of
its tunnel interface. The difference between them is that the state-
less 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 for the tunnel initiator have no relation with each
Xu, et al. Expires May 6 2012 [Page 12]
Internet-Draft SAVI Transition November 2012
other, so that the 4over6 Concentrator needs to save the mapping
relationship to provide correct forwarding. Two types of initiators
with two address relation-ships, there are 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 and
private IPv4 address and NAT in the destination network, that is, A1-
Xu, et al. Expires May 6 2012 [Page 13]
Internet-Draft SAVI Transition November 2012
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. 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,
Xu, et al. Expires May 6 2012 [Page 14]
Internet-Draft SAVI Transition November 2012
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
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 article, 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 researcher,
work together and finally we can make it happen to achieve the goal
in real transition scenarios.
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.
[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.
Xu, et al. Expires May 6 2012 [Page 15]
Internet-Draft SAVI Transition November 2012
[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 May 6 2012 [Page 16]
Internet-Draft SAVI Transition November 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 May 6 2012 [Page 17]