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, IPv4, MAC, Switch-Port> |
+--------------------+-----------+--------------------------------+
| IPv4 only | A2 |<IPv4, MAC, Switch-Port> |
+--------------------+-----------+--------------------------------+
| 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 <IP, MAC,
Switch-Port>, 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 | <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- | Dual-Stack with | <IPv6, MAC, Switch- |
| 3 | C1/C2/- | stateful scenario | Port> Concentrator |
| | (D1/D2/D3) | in Public 4over6 | verifies relationship|
| | | | 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/B2)- | DS-Lite; 4RD; A+P; | <IPv6, MAC, Switch- |
| 5 |(C1/C2/C3/C4) | Solo-Stack scenario| Port,(Port-Range)> |
| | -(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 <IPv4, MAC, Switch-Port>, 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 <IPv4, IPv6, MAC, Switch-Port> 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 <IPv6, MAC, Switch-Port> 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
<IP, MAC, Switch-Port> 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]