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