SAVI K.Xu, G.Hu, J.Bi, M.Xu Internet Draft Tsinghua Univ. Intended status: Standard Tracks F.Shi Expires: May 2012 China Telecom November 20, 2011 The Requirements and Tentative Solutions for SAVI in IPv4/IPv6 Transition draft-xu-savi-transition-00.txt Abstract 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. Unfortunately, up to now, SAVI switch only works under the scenario of pure wire/wireless IPv6 Ethernet access subnet. In the current stage of IPv4/IPv6 transition which can't be cross over, SAVI has to make more progress to adapt it. This document describes the requirements and gives tentative solutions for the SAVI in IP4/IPv6 transition period. In RFC5565, Wu et.al proposal a softwire mesh framework to address the problem of routing information and data packets of one protocol how to pass through a single-protocol network of the other protocol. According to the real situation of CNGI-CERNET and China Telecom, document takes scenario of IPv4 packets transit IPv6 network into account. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 20, 2012. Xu, et al. Expires May 20, 2012 [Page 1] Internet-Draft SAVI Transition November 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. (This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 4 3. Requirements and solutions for SAVI in IPv4/IPv6 transition.. 4 3.1. Public 4over6 .......................................... 4 3.2. Lightweight 4over6...................................... 6 4. Conclusions ................................................. 6 5. References .................................................. 6 5.1. Normative References.................................... 6 6. Acknowledgments ............................................. 6 Xu, et al. Expires May 20 2012 [Page 2] Internet-Draft SAVI Transition November 2011 1. Introduction Without a doubt, SAVI has made significant contribution for IP source address validation and anti-spoofing in the scenario of pure IPv6 Ethernet access subnet. Current situation is that IPv4 address has worn out but still takes a domination position for a long time, and IPv6 networking start to shrive. Meanwhile, SAVI switch only works at the scenarios of wire or wireless Ethernet, thus, there are lots of works have to do and many efforts need to make for adapting with the reality and promoting SAVI scheme. In the transition period from IPv4 to IPv6, approaches are classified into three types: dual stack, tunneling and translation. Regarding to real situation of CNGI-CERNET and China Telecomm which are the two of biggest Internet providers, this document mainly states the requirements and proposes some tentative solutions for scenarios of public 4over6[p4over6], lightweight 4over6[l4over6], which are the two implementations for scenario of IPv4-over-IPv6 in RFC5565. We hope that our proposal would be helpful for resolving problems of IP spoofing and validation in users' access subnet under transition period. Public IPv4 over Access IPv6 Network (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. By allocating public IPv4 addresses to end hosts/networks in IPv6, it can achieve IPv4 end-to- end bidirectional communication between these hosts/networks and IPv4 Internet. Public 4over6 can be generally considered as IPv4-over-IPv6 hub and spoke tunnel using public IPv4 address. Each 4over6 initiator will use public IPv4 address for IPv4-over-IPv6 communication. In the host initiator case, every host will get one IPv4 address; in the CPE (Customer premises equipment) case, every CPE will get one IPv4 address, which will be shared by hosts behind the CPE. There is a slight different between public 4over6 and lightweight 4over6. Briefly, lightweight 4over6 mitigates IPv4 address exhaustion by sharing public IPv4 addresses amongst users, while public 4over6 host own a unique public IPv4 address. In lightweight 4over6 scenario, several hosts share a public address but have different port range by extending DHCPv4 and PCP protocol. Xu, et al. Expires May 20 2012 [Page 3] Internet-Draft SAVI Transition November 2011 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. Requirements and solutions for SAVI in IPv4/IPv6 transition In this section, we mainly talk about the requirements for SAVI in transition period regarding to public 4over6 and IVI approaches. 3.1. Public 4over6 Figure 1 illustrates the working scenario of public 4over6. Users in an IPv6 network take IPv6 as their native service. There are two types of users: dual-stack and CPE behind. Some users are end hosts which face the ISP network directly, while others are local networks behind CPEs, such as a home LAN, an enterprise network, etc. The ISP network is IPv6-only rather than dual-stack, which means that ISP can't provide native IPv4 access to its users; however, it's acceptable that one or more routers on the carrier side become dual- stack and get connected to IPv4 Internet. So if network users want to connect to IPv4, these dual-stack routers will be their entrances". +-------------------------+ | IPv6 ISP Network | +------+ | |host: | | |initi-| | |ator |=================+-------+ +-----------+ +------+ |4over6 | | IPv4 | | IPv4-in-IPv6 |Concen-|---| Internet | +----------+ +------+ |trator | | | |local IPv4|--|CPE: |=================+-------+ +-----------+ | network | |initi-| | +----------+ |ator | | +------+ | | | +-------------------------+ Figure 1 Public 4over6 scenario Public 4over6 has stateful and stateless two working mode. Either stateful or stateless mode depends on whether it needs a mapping record for IPv4 and its corresponding IPv6 address in 4over6 Concentrator or not. The difference among them is that stateless mode Xu, et al. Expires May 20 2012 [Page 4] Internet-Draft SAVI Transition November 2011 use the IPv6 address based on IPv4 embedded and initiator and concentrator both needs to parse/compose the address, while stateful mode means concentrator should restore the mapping records for IPv4/IPv6 address. Two types of users use DHCP or PCP protocol to retrieve IP address. Two types of users multiple two types of working modes, that is four scenarios, we analyses them in detail. a) Scenario 1:Dual-stack with stateful For accessing IPv4 and IPv6 resources, this type of users owns IPv4 and IPv4 unrelated IPv6 addresses. Dual-stack hosts get their IPv6 address via DHCPv6 protocol as normal, however, IPv4 addresses allocation datagram for them need to encapsulate into tunnel, tunnel initiator is their IPv6 addresses and the 4over6 concentrator is the end of tunnel. For the reason of the toughness in access switch to parse IPv4 address from tunnel, SAVI switch only needs to snoop DHCPv6/PCP protocols and bind the relationship of , however, 4over6 concentrator validates the mapping relationship of IPv4 to IPv6. b) Scenario 2:Dual-stack with stateless Even though this type of users has both IPv4 and IPv6 address, however, any of them could conduct to another. SAVI switch saves the relationship of or would be ok. c) Scenario 3: CPE-behind with stateful In this scenario, hosts only have public IPv4 address and CPE plays the role of broker with dual-stack. SAVI switch should to snooping the DHCPv4/PCP protocols interaction and bind relationship. d) Scenario 4:CPE-behind with stateless SAVI switch does the same thing with scenario C, the difference is that the start point of tunnel is initiated by CPE which use an IPv4- mapped IPv6 address. In summary, SAVI switch should listen to the IP address allocation protocol like DHCPv6, DHCPv4, PCP etc. and bind host's properties based on working scenario. Xu, et al. Expires May 20 2012 [Page 5] Internet-Draft SAVI Transition November 2011 3.2. Lightweight 4over6 We no longer carry out a detailed description of each scenario in lightweight 4 over6 because there is nothing big changes compare with public 4over6 scheme. The difference exists in the way of host how to own an address. As mentioned before, public 4over6 host entirely own a unique public IPv4 address, while several lightweight 4over6 hosts share a public IPv4 address, but they have different port range. This change needs to extend DHCPv4[DHCPv6-map] and PCP protocol, thus, SAVI switch needs to listen to these address allocation protocols and bind relationship of . 4. Conclusions There would be a long period from IPv4 to IPv6, public 4over6 is one of practical approach for inter-communication in the transition stage. SAVI switch focus on anti-snooping in users' access subnet by binding hosts' information. But till now, it only works at IPv6 environment. This document presents the SAVI requirements in this period, and in the meanwhile, we investigated working scenarios of public 4over6 in detail and gave some tentative solutions for SAVI adaption. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5565] J.Wu, Y.Cui, C.Metz, E.Rosen, ''Softwire Mesh Framework'', RFC 5565, June 2009. [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 [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 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Xu, et al. Expires May 20 2012 [Page 6] Internet-Draft SAVI Transition November 2011 Authors' Addresses Ke Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing, 100084 China Email: xuke@mail.tsinghua.edu.cn Guangwu Hu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 China EMail: hgw09@mails.tsinghua.edu.cn Fan Shi China Telecom Beijing Research Institute, China Telecom Beijing 100035 China EMail: shifan@ctbri.com.cn Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@tsinghua.edu.cn Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 China Email: xmw@csnet1.cs.tsinghua.edu.cn Xu, et al. Expires May 20 2012 [Page 7]