The Requirements and Tentative Solutions for SAVI in IPv4/IPv6 Transition
draft-xu-savi-transition-00

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 <IPv6, MAC, Switch-
   Port>, 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 <IPv6, MAC, Switch-Port > or <IPv4, IPv6, MAC,
   Switch-Port> 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 <IPv4, MAC, Switch-
   Port> 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 <IPv4, MAC, Switch-Port, Port-range>.

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]