idnits 2.17.1 draft-xu-savi-transition-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 11, 2015) is 3082 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '14' on line 618 -- Looks like a reference, but probably isn't: '15' on line 619 -- Looks like a reference, but probably isn't: '16' on line 639 == Unused Reference: 'RFC5565' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'DHCPv6-map' is defined on line 752, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI K.Xu, G.Hu, J.Bi, M.Xu 2 Internet Draft Tsinghua Univ. 3 Intended status: Standard Tracks F.Shi 4 Expires: May 2016 China Telecom 5 November 11, 2015 7 A General Framework of Source Address Validation and Traceback for 8 IPv4/IPv6 Transition Scenarios 9 draft-xu-savi-transition-08.txt 11 Abstract 13 SAVI (Source Address Validation Improvement) is an excellent 14 mechanism for anti-IP-spoofing, which was advocated by IETF but only 15 focused on single-stack or simple network scenarios right now. To the 16 best of our knowledge, existing studies have not paid attention to 17 the IPv4/IPv6 transition scenarios. However, since IPv4/IPv6 18 transition schemes are plenty and various, one solution cannot meet 19 all requirements of them. In this draft, we present a SAVI-based 20 general framework for IP source address validation and traceback in 21 the IPv4/IPv6 transition scenarios, which achieve this by extracting 22 out essential and mutual properties from these schemes, and forming 23 sub-solutions for each property. When one transition scheme is 24 composed from various properties, its IP source address validation 25 and traceback solution is directly comprised by the corresponding 26 sub-solutions. Thus, the most exciting advantage of this framework is 27 that it is a once-and-for-all solution no matter how transition 28 schemes change. Till now, this proposal was approved by China 29 Communications Standards Association (CCSA), and we will actively 30 promote it to apply real network scenarios. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 11, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents carefully, 57 as they describe your rights and restrictions with respect to this 58 document. Code Components extracted from this document must include 59 Simplified BSD License text as described in Section 4.e of the Trust 60 Legal Provisions and are provided without warranty as described in 61 the Simplified BSD License. 63 (This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 10 65 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction ............................................. 3 78 2. Conventions used in this document ........................ 4 79 3. Framework description .................................... 5 80 3.1. Property Extraction ................................... 5 81 3.2. Solutions of IP source address validation ............. 7 82 3.3. Solutions to IP source address traceback ............. 10 83 4. Framework verification .................................. 13 84 4.1. Public 4over6 ........................................ 13 85 4.2. 6RD .................................................. 14 86 4.3. DS-Lite .............................................. 14 87 4.4. 4RD .................................................. 15 88 4.5. A+P .................................................. 15 89 4.6. IVI .................................................. 15 90 5. Framework implementation ................................ 15 91 6. Conclusions ............................................. 16 92 7. References .............................................. 17 93 7.1. Normative References.................................. 17 94 8. Acknowledgments ......................................... 18 96 1. Introduction 98 The issue of IP source address spoofing has become very serious in 99 recent years. According to the IP spoofer project of MIT, the 100 proportion of spoofable netblocks, IP addresses and autonomous 101 systems are 14.6%, 16.3%, 23.9%, respectively [MITSpoofer]. This was 102 result from the absence of intrinsic mechanism of IP source address 103 validation. Encouragingly, this issue was noticed gradually by many 104 researchers and lots of excellent solutions were proposed. One of 105 them is the SAVI [SAVI] (Source Address Validation Improvement) 106 scheme which is proposed by IETF SAVI workgroup. The mechanism of it 107 is binds host's IP, MAC address, uplink port in the user access 108 switch by snooping host's IP assignment protocol. The switch which 109 followed the SAVI proposal, namely SAVI Switch, eliminates this issue 110 in the first-hop of packets. Binding function in SAVI Switch is 111 automatically accomplished by snooping IP address assignment 112 protocols, e.g. DHCPv6, SLAAC. Thus, It is more accurate and 113 effective than the URPF [RFC3704] (Unicast Reverse Path Forwarding) 114 proposal because it takes effect in the position of user's layer2 115 access switch rather than access router. According to the charter of 116 SAVI workgroup, it would cover wire/wireless Ethernet network, and 117 both protocols of IPv4 and IPv6 as well. Till now, various commodity 118 SAVI Switch products have already been implemented by lots of network 119 equipment providers, for instance, Huawei, ZTE etc. 121 On the other hand, since bothered by stubborn issues of IPv4 Internet, 122 including exhaustion of IPv4 address, people gradually turn their 123 attention from IPv4 to IPv6 Internet. Most ISPs are progressively 124 developing their IPv6 networks and lead to the IPv6 Internet presents 125 a rapid development trend in recent years. However, in a short period, 126 traditional IPv4 Internet will not disappear very soon, on the 127 contrary, it will still take the dominated position for a long time 128 with the reason of man-power, money cost and so on. As a matter of 129 fact, the IPv6 Internet traffic only accounts for 1% of the total 130 Internet traffic. In other words, the two kinds of networks will be 131 coexistence for a long period. In view of this situation, plenty of 132 schemes for promoting intercommunication between the two networks 133 have been proposed, such as IVI[RFC6219], DS-Lite[RFC6333], 4RD[4RD], 134 A+P[RFC6346] and Public 4over6[p4over6]. In the light of work mode, 135 they are categorized into three types: dual-stack, translation and 136 tunnel. In terms of tunnel technology, it is also known as 137 "softwires"[RFC5565] which provides packet transit service from one 138 edge of single-protocol network to other. 140 Although many mature and practical solutions have met the demand of 141 validating IP source address and even traceback in single-stack 142 networks, but to the best of our knowledge, ideas for the same 143 purpose in the IPv4/IPv6 transition scenarios have not been explored 144 yet. The difficulty lies in it is that, it's inflexible to propose 145 corresponding scheme for each one plan since they are plenty and 146 various. Viewed this challenge and dilemma, proposing solo general 147 and feasible solution which can satisfy all the requirements of these 148 transition plans has become the single goal of this draft. 150 After investigated almost all the transition especially tunnel 151 schemes, we have found that there exist basic and common properties 152 among them. Then, we focus on extracting these essential properties 153 from these schemes and then forming sub-solutions for each property 154 with the help of SAVI. Consequently, when one scheme is constituted 155 by required properties, its source address validation and traceback 156 solution are naturally combined by corresponding sub-solutions. Thus, 157 our framework is a once-and-for-all solution no matter how transition 158 plans will change. 160 Since authors of this draft participate in both SAVI and Softwire 161 IETF workgroup long-termly, we naturally used the ideas of SAVI to 162 achieve it. Like we mentioned, our purpose is present a feasible 163 general anti-spoofing framework for transition scenarios and give 164 more inspiration to interested people, but limited by the 165 uncontrollable factors, like personal privacy, law permission, 166 implementation detail, framework's performance evaluation, expanding 167 SAVI out of LAN environment or not, we will not refer to. 169 In addition, more of the details we have been discussed in the paper 170 ''A General Framework of Source Address Validation and Traceback for 171 IPv4/IPv6 Transition Scenarios'', which was published in Nov.2013 172 issue of IEEE Network. Interesting reader can refer to it and discuss 173 with us about your concerns in anytime. 175 2. Conventions used in this document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in 180 [RFC2119]. 182 3. Framework description 184 In this section, we firstly give the threat model and its 185 considerations, and then describe our framework in detail. 187 The threat model in this paper we refer to the fields in an IP packet 188 can be tampered as the spoofer's will, and when these packets arrived 189 their destination, spoofer can run in the attack or purposed action 190 and it's hard to locate the perpetrator since the packet's source IP 191 address has been modified. But we believe that the network devices or 192 middle-boxes (NAT, tunnel points, protocol translator etc.) are 193 trustful and attackers cannot manipulate them. Otherwise, that 194 situation would become very complex and it's beyond our agenda. 196 To keep packets carried with the trusted IP source address, it should 197 let the packets come from an authorized user who is the owner of the 198 packet's source address, and prevent spoofed packets from being 199 forwarded. Naturally, the straight-forward idea of us is to deploy 200 SAVI Switch into users' subnet to keep the trustiness of all hosts. 201 Furthermore, NAT devices need to save the pre-translate and post- 202 translate addresses mapping records. Such ideas could directly 203 facilitate the implementation of the traceback function. 205 3.1. Property Extraction 207 Like we mentioned, it is difficult to require one framework to adapt 208 to all transition plans. But since there exist common properties in 209 these transition schemes, establishing such framework could be 210 possible if we could extract these essential properties from these 211 plans and restore them by reassembling required properties. Actually, 212 this has been achieved based on three property extraction rules: 1) 213 It only extracts essential elements and does not take irrelevant 214 details into account; 2) every element should not be further 215 decomposed (in other words, each element should be atomic and unique); 216 3) it should have the reconstruction capability of reassembling 217 required elements. The result of the property extraction is 218 illustrated as table I. 220 We have summarized these properties into four categories with 12 221 items. Property group A states the stacks of spoofer's running rather 222 than its network environment. The stateless in Group B means that 223 IPv4 and IPv6 addresses are tight related since they can be deduced 224 with each other, while the stateful declares that the two kinds of 225 addresses has no relation so that the tunnel terminal needs to save 226 the mapping relationship for forwarding. Property items C3 and C4 227 which describe the scenario where multi-hosts share one IPv4 address 228 by splitting the port-range. The last property group D depicts the 229 positions of NAT device which could change the source IP address not 230 only within the form of private to public and shared to non-shared. 231 Properties D1, D2 and D3 manifest the NAT devices in the position of 232 the local network, the destination network with same protocol-stack 233 of the local network, and both sides separately. 235 As the property item combination, we must point out two confusion 236 places. The first one is A3 with group C are not conflicting with 237 each other because the source host can retrieve IPv4 address by 238 taking itself as tunnel start-point even in a IPv6 network, as well 239 as C2 or C3 with group D since network address translation(NAT) has 240 various forms not just only refer the private to the public. 241 Therefore, the maximum number is 72 and the minimum is 2 since 6over4 242 transition only needs A3 combine with B1 or B2, and group D is not a 243 necessary condition for 4over6 transition regard to the item 244 combination. 246 Table I. Properties in transition schemes 248 +--------------------+-----------+-------------------------+------+ 249 | Property Group |Group Code | Property Name | Value| 250 +--------------------+-----------+-------------------------+------+ 251 |The protocol stacks | A | Dual-Stack | A1 | 252 |of source host | |-------------------------+------+ 253 | | | IPv4 only | A2 | 254 | | |-------------------------+------+ 255 | | | IPv6 only | A3 | 256 +--------------------+-----------+-------------------------+------+ 257 |Relationships | B | Stateless | B1 | 258 |between IPv4 and | |-------------------------+------+ 259 |IPv6 Address | | Stateful | B2 | 260 +--------------------+-----------+-------------------------+------+ 261 |Forms of 4over6 | C | Private | C1 | 262 |hosts' IPv4 address | +-------------------------+------+ 263 | | | Public | C2 | 264 | | +-------------------------+------+ 265 | | | Public with Port Sharing| C3 | 266 | | +-------------------------+------+ 267 | | |Private with Port Sharing| C4 | 268 +-----------------------------------------------------------------+ 269 |The locations of NAT| D | Only in local side | D1 | 270 |devices for source | +-------------------------+------+ 271 |host | | Only in dest.side | D2 | 272 | | +-------------------------+------+ 273 | | | D1 & D2 | D3 | 274 +-----------------------------------------------------------------+ 276 3.2. Solutions of IP source address validation 278 Keeping packets bringing with trustful IP source addresses is the 279 foundation of the traceback and other applications. SAVI Switch can 280 achieve this goal, but till now, it's only applicable for the single- 281 stack network, which means SAVI Switch needs to be improved to adapt 282 to dual-stack and other complex scenarios. In the other sides, it is 283 not inflexibility to enumerate all the possibilities of property 284 combinations and separately considering how to achieve our goal. 285 Instead, we present the sub-solutions to IP source address validation 286 for each property with the help of SAVI Switch, as illustrated in 287 table II. 289 Table II. Solutions of Source address validation for each property 291 +--------------------+-----------+--------------------------------+ 292 | Property Name | Value | Measurements in SAVI Switch | 293 +--------------------+-----------+--------------------------------+ 294 | Dual-Stack | A1 | | 295 +--------------------+-----------+--------------------------------+ 296 | IPv4 only | A2 | | 297 +--------------------+-----------+--------------------------------+ 298 | IPv6 only | A3 | | 299 +--------------------+-----------+--------------------------------+ 300 | Stateless | B1 | none | 301 +--------------------+-----------+--------------------------------+ 302 | Stateful | B2 | none | 303 +--------------------+-----------+--------------------------------+ 304 | Private | C1 | none | 305 +--------------------+-----------+--------------------------------+ 306 | Public | C2 | none | 307 +--------------------+-----------+--------------------------------+ 308 | Public with Port-S | C3 | property A & port-range | 309 +--------------------+-----------+--------------------------------+ 310 | Private with Port-S| C4 | property A & port-range | 311 +--------------------+-----------+--------------------------------+ 312 | Near to CPE | D1 | | 313 +--------------------+-----------| | 314 | Near to CGN AFTR | D2 | NAT devices record the | 315 +--------------------+-----------| NAT-Table | 316 | D1 & D2 | D3 | | 317 +--------------------+-----------+--------------------------------+ 319 Since the property item which is either the stateless (B1) or the 320 stateful (B2) only decides the relationship between the two types of 321 addresses for source hosts, the sub-solutions to their source address 322 validation depend on property group A. Similarly, sub-solutions to 323 source address validation for property items C1 and C2 are all 324 decided by property group A as well. However, if it is the situation 325 where multi-hosts share an IP address by the multiplexing upper port, 326 SAVI Switch should bind its port-range together along with group A 327 required, Property group D needs save the NAT-Table for traceback. 329 Table III. Solutions of Source address validation for property 330 combinations 332 +------+--------------+--------------------+----------------------+ 333 |Index | Combination |Transition Scenario |Solutions in SAVI Swi.| 334 +---------------------+--------------------+----------------------+ 335 | | A1-B1- | Dual-Stack with | | 337 | | (D1/D2/D3) | in Public 4over6 | | 338 +---------------------+--------------------+----------------------+ 339 | | A1-B1- | Dual-Stack with | | 342 | | | Public 4over6 | | 343 +---------------------+--------------------+----------------------+ 344 | | A1-B2- | DS-Lite; | Concentrator | 346 | | (D1/D2/D3) | stateful scenario | verifies relationship| 347 | | | in Public 4over6 | of | 348 +---------------------+--------------------+----------------------+ 349 | | A1-B2- | Dual-Stack with | Concentrator | 351 | | (D1/D2/D3) | in Light-Weighted | verifies relationship| 352 | | | Public 4over6 | of | 353 +---------------------+--------------------+----------------------+ 354 | | A2-B1- | 4RD; | | 356 | | (D1/D2/D3) | stateless scenario | | 357 | | | in public 4over6 | | 358 +---------------------+--------------------+----------------------+ 359 | | A2-B1- | A+P; | | 361 | | (D1/D2/D3) | stateless scenario | | 362 | | | in Light-Weighted | | 363 | | | Public 4over6 | | 364 +---------------------+--------------------+----------------------+ 365 | | A2-B2- | IPv4-only with | | 367 | | (D1/D2/D3) | in public 4over6 | | 368 +---------------------+--------------------+----------------------+ 369 | | A2-B2- | IPv4-only with | | 371 | | (D1/D2/D3) | in Light-Weighted | | 372 | | | Public 4over6 | | 373 +---------------------+--------------------+----------------------+ 374 | 9 | A3-B1 | 6RD; || 375 +---------------------+--------------------+----------------------+ 376 | 10 | A3-B2 | | same with row index 9| 377 +---------------------+--------------------+----------------------+ 378 We also consider the solution to the source address validation for 379 property combinations. In table III, the notation ''-'' in column of 380 ''Combination'' means the relation of union, while the slash notation 381 indicates single choice from multi-option, and the bracket states the 382 optional relationship. Taking the combination A1-B1-C1/C2-(D1/D2/D3) 383 as an example, it depicts that property item A1 combines with B1, and 384 then they as a whole unite with either C1 or C2. This combination 385 could be further preceded with any property items in group D. 387 Even though we can bind two kinds of address and other information 388 together in dual-stack network, for the consistent reason and 389 considering the performance of SAVI Switch in parsing DHCPv4(6) 390 messages from the upper tunnel protocol in scenarios which involved 391 with A2 and A3, we turn to an alternative approach where the switch 392 only binds IPv4(6) with other information. And tunnel terminal snoops 393 IPv4/IPv6 address assignment protocols in order to save the records 394 of IPv4-IPv6 (stateful), and verifies it for each packet either in 395 stateless or stateful scenarios, as row index from 1 to 4. 397 3.3. Solutions to IP source address traceback 399 The traceback means that system can locate the senders of the 400 suspicious packets original from. To achieve this goal, IP source 401 address in every packet should be authentic and trustful. This can be 402 implemented by authenticating the sender in SAVI Switch and recording 403 the IP mapping-table in each NAT device. Finally, administrators can 404 track down the sender by following the path from the packet receiver 405 to the sender. Table IV presents the method of traceback for 406 individual property. 408 In the stateless scenarios, a very tough problem exists for the 409 traceback; that is, it's hard to locate the device of tunnel 410 initiator from the side of the tunnel terminal because the interface 411 address of the tunnel is packets' source address related to IPv6(4) 412 address, rather than the tunnel-device's address. It will become much 413 easier if the tunnel terminal has the mapping-relationship with the 414 tunnel's interface address and the tunnel-device's address. Thus, we 415 have the approach to extending IP header of the tunnel protocol to 416 include the tunnel-device's address, and tunnel terminal saves this 417 mapping-relationship. 419 As to the question of how to extend IP header to achieve this goal, 420 it is a relatively minor issue which can be realized by creating a 421 new option in IPv6 destination header or utilizing rarely-used fields 422 in IPv4 header. We have to admit that we do sacrifice some cost for 423 traceback in this situation, but as a comprehensive research we still 424 present out and let the network authorities to make their choices. 426 Besides, another key issue is the SAVI Management Database (SMD) 427 which collects information from all SAVI Switches in domain by SNMP 428 protocol, including the binding-status-table and other important data. 429 Therefore, administrators could directly lock the source-host by 430 consulting this database with its IP source address or other 431 distinctive conditions. 433 Table IV. Sub-Solutions to traceback for single property 434 +-----------+-----------------------------------------------------+ 435 | Value | Measurements | 436 +-----------+-----------------------------------------------------+ 437 | A1 | Queried IPv4 address->deduce(stateless) or look up | 438 | | table(stateful)->IPv6->locate | 439 +-----------+-----------------------------------------------------+ 440 | A2 | Depends on group B | 441 +-----------+ | 442 | A3 | | 443 +-----------+-----------------------------------------------------+ 444 | B1 | Extend IP header to include tunnel initiator's | 445 | | address, and tunnel terminal saves relationship of | 446 | | | 448 +-----------+-----------------------------------------------------+ 449 | B2 | IPv6(4) address is obtained by looking up IPv4-IPv6 | 450 | | mapping-table in 4over6 terminal | 451 +-----------+-----------------------------------------------------+ 452 | C1 | Depends on A | 453 +-----------+-----------------------------------------------------+ 454 | C2 | Depends on A | 455 +-----------+-----------------------------------------------------+ 456 | C3 | Take port number with IPv4 address as condition to | 457 | | query 'Binding Status Table' in SAVI Switch | 458 +-----------+-----------------------------------------------------+ 459 | C4 | Same with C3 | 460 +-----------+-----------------------------------------------------+ 461 | D | Take queried IPv4 address as condition to retrieve | 462 | | original IPv4 address by looking up NAT table | 463 +-----------+-----------------------------------------------------+ 465 Table V. Solutions to IP traceback for property combinations 467 +------+--------------+--------------------+----------------------+ 468 |Index | Combination | 4over6 Plans | Track Path | 469 +---------------------+--------------------+----------------------+ 470 | | A1-B1- | Dual-Stack with | Queried v4->(Original| 471 | 1 | C1/C2/- | stateless scenario | v4 (via D2))->v6 (via| 472 | | (D1/D2/D3) | in Public 4over6 | deduce)-> lock sender| 473 +---------------------+--------------------+----------------------+ 474 | | A1-B1- | Dual-Stack with | same with row index 1| 475 | 2 | C3/C4/- | stateless scenario | | 476 | | (D1/D2/D3) | in Light-Weighted | | 477 | | | Public 4over6 | | 478 +---------------------+--------------------+----------------------+ 479 | | A1-B2- | DS-Lite; | Queried v4->(Original| 480 | 3 | C1/C2/- | Dual-Stack with | v4 (via D2))->v6 (via| 481 | | (D1/D2/D3) | stateful scenario | look table)->lock | 482 | | | in Public 4over6 | sender | 483 +---------------------+--------------------+----------------------+ 484 | | A1-B2- | Dual-Stack with | same with row index 3| 485 | 4 | C3/C4/- | stateful scenario | | 486 | | (D1/D2/D3) | in Light-Weighted | | 487 | | | Public 4over6 | | 488 +---------------------+--------------------+----------------------+ 489 | | A2-B1- | 4RD; | Queried v4->(Original| 490 | 5 | C1/C2- | IPv4-only with | v4 (via D2))->v6 (via| 491 | | (D1/D2/D3) | stateless scenario | deduce)-> lock | 492 | | | in public 4over6 | tunnel initiator-> | 493 | | | | (original v4(via D1))| 494 | | | | ->locate sender | 495 +---------------------+--------------------+----------------------+ 496 | | A2-B1- | A+P; | same with row index 5| 497 | 6 | C3/C4- | IPv4-only with | | 498 | | (D1/D2/D3) | stateless scenario | | 499 | | | in Light-Weighted | | 500 | | | Public 4over6 | | 501 +---------------------+--------------------+----------------------+ 502 | | A2-B2- | IPv4-only with | Queried v4->(Original| 503 | 7 | C1/C2- | stateful scenario | v4 (via D2))->v6 (via| 504 | | (D1/D2/D3) | in public 4over6 | look table)->lock-> | 505 | | | | tunnel initiator-> | 506 | | | | (original v4(via D1))| 507 | | | | ->locate sender | 508 +---------------------+--------------------+----------------------+ 509 | | A2-B2- | IPv4-only with | same with row index 7| 510 | 8 | C3/C4- | stateful scenario | | 511 | | (D1/D2/D3) | in Light-Weighted | | 512 | | | Public 4over6 | | 513 +---------------------+--------------------+----------------------+ 514 | 9 | A3-B1 | 6RD; |Queried v6->(via | 515 | | | |deduce->locate tunnel | 516 | | | |initiator (via look | 517 | | | |table)->locate sender | 518 +---------------------+--------------------+----------------------+ 519 | 10 | A3-B2 | | same with row index 9| 520 +---------------------+--------------------+----------------------+ 522 Table 5 illustrates the fully track-path for property combinations. 523 Taking the first row in this table as an example, we try to locate 524 the sender of a suspicious packet in the destination network. The 525 first step is to look up the NAT mapping-table to retrieve the 526 original IPv4 address if there exists an NAT device. Since it's the 527 dual-stack and stateless scenario, the source-host uses its own IPv6 528 as the tunnel interface's address to forward its own IPv4 packets; 529 this IPv6 address can be deduced from its pre-translated IPv4 address. 530 Finally, the sender will be located by consulting SMD based on its 531 IPv6 address. 533 4. Framework verification 535 In this section, we apply our framework to some famous previous 536 mentioned schemes to verify its correctness. 538 4.1. Public 4over6 540 Packets with public IPv4 addresses over IPv6 networks, namely Public 541 4over6, are the mechanism for bi-directional IPv4 communication 542 between IPv4 Internet and IPv4 networks which are both sited in IPv6 543 access network. 545 Fig.1 shows the general scenario in Public 4over6 plans. The 4over6 546 Concentrator acts as a tunnel end-point receiving packets from 4over6 547 tunnel initiators and forwarding them to IPv4 Internet, while the CPE 548 (Customer Premises Equipment) device performs as a tunnel broker for 549 the solo-stack 4over6 host on the border of the local IPv4 network. 550 Another type of 4over6 hosts in IPv6 network gets their IPv4 551 addresses and accesses IPv4 Internet by using their own IPv6 552 addresses as a tunnel broker, thus, we classify it into the dual- 553 stack category. There are also two kinds of relationship between the 554 IPv4 address belongs to 4over6 host and the IPv6 address belongs to 555 its tunnel interface, that is, stateful and the stateless. The 556 difference between them is that the stateless mode takes IPv4- 557 embedded IPv6 as the tunnel initiator's address, on contrary, the 558 stateful means IPv4 address for the 4over6 host and the IPv6 address 559 for the tunnel initiator have no relation with each other, so that 560 the 4over6 Concentrator needs to save the mapping relationship to 561 provide correct forwarding. Two types of initiators with two address 562 relationships, there are total four scenarios: solo-stack with the 563 stateless (A2-B1-C2), dual-stack with the stateful (A1-B2-C2), solo- 564 stack with the stateful (A2-B2-C2) and dual-stack with the stateless 565 (A1-B1-C2). Their source addresses and traceback solutions can be 566 referred to previous tables. 568 +-------------------------+ 569 | IPv6 ISP Network | 570 +------+ | 571 |host: | | 572 |initi-| | 573 |ator |=================+-------+ +-----------+ 574 +------+ |4over6 | | IPv4 | 575 | IPv4-in-IPv6 |Concen-|---| Internet | 576 +----------+ +------+ |trator | | | 577 |local IPv4|--|CPE: |=================+-------+ +-----------+ 578 | network | |initi-| | 579 +----------+ |ator | | 580 +------+ | 581 | | 582 +-------------------------+ 584 Figure 1 The overview of Public 4over6 transition scenario 586 4.2. 6RD 588 6RD (IPv6 Rapid Deployment on IPv4 Infrastructures) is a typical 589 6over4 tunnel transition scheme. The 6rd ''Customer Edge'' (CE) router 590 functions as a tunnel broker to encapsulate and forward packets for 591 the source-host on the border of the local IPv6 network, while 6rd 592 Border Relay (BR) router located at the SP premises acts as a tunnel 593 terminal to de-capsulate and relays packets to IPv6 Internet. It 594 belongs to the stateless scenario since the IPv6 address of the 595 source-host and IPv4 address of CE WAN interface can be conducted to 596 each other. Therefore, 6RD belongs to the combination of A3-B1. 598 4.3. DS-Lite 600 Dual-Stack lite is a 4over6 transition plan. NAT function is 601 performed in CGN (Carrier Grade NAT) device to provide the 602 translation function from the private to the public IPv4 address. We 603 treat DS-Lite as the property combination of the Dual-Stack, stateful 604 and private IPv4 address and NAT in the destination network, that is, 605 A1-B2-C1-D2. According to the framework, the access SAVI Switch for 606 CPE (home gateway) should bind its IPv6, MAC address and the uplink 607 port together. Since the NAT and tunnel function fulfilled by CGN 608 device and their records are in a same table, the trace path follows 609 the direction from the queried IPv4 address to tunnel property by 610 referring to the NAT record. Then it locates CPE device in user's 611 household by following the tunnel information. 613 4.4. 4RD 615 IPv4 Residual Deployment (4RD) is a 4over6 mechanism to facilitate 616 IPv4 residual deployment across IPv6 networks of ISP's. It can be 617 treat as the combination of A2-B1-C2. More information is the 618 Softwire workgroup has decided to put 4RD and MAP-T[14] on 619 experimental track and MAP-E[15] on standards track. 621 4.5. A+P 623 The address-plus-port (A+P) approach also is 4over6 plan which 624 advocated by the France Telecom, Nokia and other companies for 625 resolving the issue of IPv4 address shortage. A+P treats some bits 626 from the port number in the TCP/UDP header as additional end-point 627 identifiers to extend the address field. A+P is an architecture which 628 combines MAP-E, MAP-T and 4RD. Although proposer described as a 629 stateful version but the IETF still put it into a stateless solution, 630 thus, we treat it as a property combination of A2-B1-C3-D1. 632 4.6. IVI 634 IVI is a typical translation transition solution which provides 635 bilateral access from both pure single stack sides. The service 636 providers reserve a piece of range IPv4 address (IVI4) so that they 637 can map them with a special range of IPv6 address (IVI6) as the 638 ration of 1:1, then the IVI translator keeps the communication 639 correctly. Another ration of 1(IPv4):N(IPv6) was called DIVI[16] 640 which implemented by splitting port only supports IPv6 initiated 641 communication. But no matter which type, the anti-spoofing measure is 642 same with pure stack which follows the SAVI's specification, and 643 keeping the stateless mapping records in order to trackback. 645 5. Framework implementation 647 The framework implementation is actually quite simple, which has been 648 illustrated by table VI. We categorized the modules into four types 649 and each type has its own deployment position. There are two special 650 occasions we must address. One is that, when a source-host is in an 651 IPv4 with port-sharing network, the binding module in SAVI Switch 652 should bind the host's port-range with other data together; and the 653 other is that, when the traceback is in tunnel stateless scenarios, 654 we need to extend the tunnel IP header that we mentioned above. 656 Table VI. MODULE DECOMPOSITION FOR FRAMEWORK REALIZATION 657 +--------+------------+--------------------+----------------------+ 658 |Modules | Deployment | Scenarios | Module Detail | 659 +--------+------------+--------------------+----------------------+ 660 |Binding |SAVI Switch | IPv4-only(Including| | 662 | | |--------------------+----------------------+ 663 | | |IPv6-only&dual-stack| | 665 +---------------------+--------------------+----------------------+ 666 |Verific |Tunnel | Stateless |Verify the deduction | 667 |ation |Terminal | |relationship | 668 | | |--------------------+----------------------+ 669 | | | Stateful |Save and verify the | 670 | | | |mapping relationship | 671 +--------+------------+--------------------+----------------------+ 672 |NAT |NAT Device& | |Record Mapping | 673 |Record |Translator | |relationship | 674 +--------+------------+--------------------+----------------------+ 675 |Trace- |Tunnel | Tunnel initiator extends packets'IP header| 676 |back |Initiator | to include relationship | 678 | +------------+-------------------------------------------+ 679 | |Tunnel | Tunnel terminal saves the above | 680 | |Terminal | relationship for traceback | 681 +--------+------------+-------------------------------------------+ 683 6. Conclusions 685 Along with the rapid development of IPv6 networks and the urgent 686 demand of inter-communication between IPv4 and IPv6 networks, the 687 situation of IPv4/IPv6 transition is inevitable, and lots of 688 transition plans are proposed. Simultaneously, the IP spoofing issue 689 still bothers network users and administrators, and once it happened, 690 it's hard to trace the spoofer. The SAVI proposal, one of the 691 excellent solutions to the source address validation, has been 692 proposed by IETF SAVI workgroup, which binds host's IP, MAC address 693 and uplink-port features in their access switches to achieve the goal 694 of preventing nodes attached to the same IP link from spoofing each 695 other's IP addresses. Our goal is to propose a general framework 696 which can adapt to all transition especially tunnel plans for IP 697 source address validation and traceback with the help of SAVI. In 698 this draft, we propose a general framework for anti-spoofing and 699 traceback in IPv4/IPv6 transition scenario by extracting the 700 essential and mutual properties from various transition schemes. We 701 present the sub-solutions or solutions for each property and property 702 combinations. Finally, we verify this framework in various transition 703 schemes and prove its excellent adaptability and flexibility. We hope 704 that it will give more inspiration for more interested researchers, 705 work together and finally we can make it happen to achieve the goal 706 in practical. In the future, we are planning to establish a platform 707 with SDN (Software Defined Networking) mechanism to realize this 708 framework. 710 7. References 712 7.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [MITSpoofer] MIT Spoofer project http://spoofer.csail.mit.edu/ 718 summary.php. 720 [SAVI] J.Wu,J.Bi et.al., ''Source Address Validation Improvement 721 Framework (SAVI)'', RFC 7039, October 2013. 723 [RFC3704] F. Baker,P. Savola, ''Ingress Filtering for Multihomed 724 Networks'', RFC3704, March 2004. 726 [RFC6219] X.Li, C.Bao etl, ''The China Education and Research Network 727 (CERNET) IVI Translation Design and Deployment for the 728 IPv4/IPv6 Coexistence and Transition'', RFC6219, May 2011. 730 [RFC6333] A.Durand,R.Droms,J.Woodyatt etl, ''Dual-Stack Lite Broadband 731 Deploy-ments Following IPv4 Exhaustion'', RFC6333,August 732 2011. 734 [4RD] R. Despres, Ed., S. Matsushima, T. Murakami etl, ''IPv4 Residual 735 Deployment across IPv6-Service networks (4rd) ISP-NAT's 736 made optional draft-despres-intarea-4rd-01'', Internet-Draft, 737 March 2011. 739 [RFC6346] R. Bush, Ed, ''The Address plus Port (A+P) Approach to the 740 IPv4 Address Shortage'', RFC6346, August 2011, 742 [p4over6] Y.Cui, J.Wu, P.Wu, C.Metz, O.Vautrin, Y.Lee, "Public IPv4 743 over Access IPv6 Network draft-cui-softwire-host-4over6-06", 745 [RFC5565] J.Wu, Y.Cui, C.Metz, E.Rosen, ''Softwire Mesh Framework'', 746 RFC 5565, June 2009. 748 [l4over6] Y.Cui, J.Wu, P.Wu, Q. Sun, C. Xie, C. Zhou, Y.Lee, " 749 Lightweight 4over6 in access network draft-cui-softwire-b4- 750 translated-ds-lite-04", Internet-Draft, Oct. 2011 752 [DHCPv6-map] T. Mrugalski, M. Boucadair, O. Troan, X. Deng, C. Bao, 753 "DHCPv6 Options for Mapping of Address and Port draft-mdt- 754 softwire-map-dhcp-option-01'', Internet-Draft, Oct. 2011 756 8. Acknowledgments 758 This document was prepared using 2-Word-v2.0.template.dot. 760 Authors' Addresses 762 Ke Xu 763 Tsinghua University 764 Department of Computer Science, Tsinghua University 765 Beijing, 100084 766 China 767 Email: xuke@mail.tsinghua.edu.cn 769 Guangwu Hu 770 Tsinghua University 771 Department of Computer Science, Tsinghua University 772 Beijing 100084 773 China 774 EMail: hgw09@mails.tsinghua.edu.cn 776 Fan Shi 777 China Telecom 778 Beijing Research Institute, China Telecom 779 Beijing 100035 780 China 781 EMail: shifan@ctbri.com.cn 783 Jun Bi 784 Tsinghua University 785 Network Research Center, Tsinghua University 786 Beijing 100084 787 China 788 Email: junbi@tsinghua.edu.cn 790 Mingwei Xu 791 Tsinghua University 792 Department of Computer Science, Tsinghua University 793 Beijing 100084 794 China 795 Email: xmw@csnet1.cs.tsinghua.edu.cn