Network Working Group N. Matsuhira Internet-Draft Fujitsu Limited Intended status: Informational January 4, 2012 Expires: July 7, 2012 Motivation for developing Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) draft-matsuhira-sa46t-motivation-01 Abstract This document describe a motivation for developing IPv4 over IPv6 encapsulation / decapsulation solution from standing position of Stateless Autimatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) and SA46T with address sharing (SA46T-AS). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 July 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Matsuhira Expires July 7, 2012 [Page 1] Internet-Draft Motivation for SA46T January 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Recongition of IPv6 Transtion stage . . . . . . . . . . . . . . 3 2.1. Stages of IPv6 Transition . . . . . . . . . . . . . . . . . 3 2.2. IPv4 address exhaution . . . . . . . . . . . . . . . . . . 3 2.3. Current stage of IPv6 Transition . . . . . . . . . . . . . 3 3. Motivation of developing SA46T and SA46T-AS . . . . . . . . . . 4 4. Designe goal . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Can install into existing network . . . . . . . . . . . . . 4 4.2. Less tunnel configuration . . . . . . . . . . . . . . . . . 5 4.3. Simple install strategy . . . . . . . . . . . . . . . . . . 5 4.4. Can treat both IPv4 Global and IPv4 Privates . . . . . . . 5 4.5. Can install into varius networks . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Matsuhira Expires July 7, 2012 [Page 2] Internet-Draft Motivation for SA46T January 2012 1. Introduction This document describe a motivation for developing IPv4 over IPv6 encapsulation / decapsulation solution from standing position of Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)[I-D.draft-matsuhira-sa46t-spec] and SA46T with address sharing (SA46T-AS)[I-D.draft-matsuhira-sa46t-as]. 2. Recongition of IPv6 Transtion stage 2.1. Stages of IPv6 Transition There is an idea that divited the transiton from IPv4 to IPv6 into three stages, early stage, middle stage and end stage. In early stage, majority of the Internet are based on IPv4, so IPv6 over IPv4 tunneling technologies are considerd to be useful. In middle stage, majority of the Internet are based on Dual Stack (Both IPv4 and IPv6), so both IPv4 and IPv6 will treat as is, and no major tunneling technologies are considerd to be use. In end stage, majority of the Internet are based on IPv6, so IPv4 over IPv6 tunneling technologies are considerd to may be useful as option, because dual stack based operation still effective in end stage. It seems that a lot of people should have thought that the majority of transiton to IPv6 are completed before the IPv4 address exhaustion. In this recognition, IPv4 over IPv6 tunneling solution is not indispensable, but is some operational option, exclude artifical made IPv6 only network. 2.2. IPv4 address exhaution The IPv4 address exhaution already became the real. In 03-Feb-2011, IANA Unallocated Address Pool was exhausted. And in 19-Apr-2011, APNIC unallocated address pool was exhaused. Other RIRs, unallocated address pool does not exhaused now, however, it should be a matter of time. For more details, please refer to IPv4 address report , http://www.potaroo.net/tools/ipv4/. The IPv4 address exhaution has already become the reality. That mean that the environment of IPv6 only also becomes the reality, too. 2.3. Current stage of IPv6 Transition When paying attention to IPv6 traffic, current stage of IPv6 transiton should be very very early stage, however IPv4 address exhaution is the reality. Matsuhira Expires July 7, 2012 [Page 3] Internet-Draft Motivation for SA46T January 2012 It should be recognized that a big gap is caused between the situation of IPv6 deployment and the situation of IPv4 address supply. IPv4 is still majority now, and there are few IPv6 environment except research networks. It is not easy to change from IPv4 to IPv6 suddenly especially servers or services. That mean, IPv4 address still required for continuance of current IPv4 service with necessary minimum enhancing. 3. Motivation of developing SA46T and SA46T-AS The IPv4 traffic is generated by the IPv4 host. On the other hand, in general, to carry the IPv4 traffic, the IPv4 routing function is necessary. However, if the IPv4 over IPv6 tunneling technology is used, it is enough by the IPv6 routing function. Following are the motivation of developing SA46T. o Develop simple and scalable IPv4 over IPv6 encapsulation / decapsulation technology. o Enabele single stack operaton by IPv6 in the backbone network. o Can collect the IPv4 global address from where it is not indispensable, and reallocate the IPv4 global address to where it is indispensable. o Can still use IPv4 address (both global and private) with access environments is IPv6 only. o Support IPv4 address reuse and IPv4 address sharing if necessary. o Can deploy to IPv6 in stub network with their own peace 4. Designe goal 4.1. Can install into existing network The IPv4 address can be collected only from an existing network where the IPv4 address is used. Therefore, it is necessary to be able to install it into an existing network. Of cource, It is possible to use it even on a new network. Matsuhira Expires July 7, 2012 [Page 4] Internet-Draft Motivation for SA46T January 2012 4.2. Less tunnel configuration In a existing tunnel technique, the configuration of N^2 piece is needed for number N of tunnels end points connecting for full mesh topology. When N is small, it is not a problem, however when N is large, many many configuration required, then reality disappear. It cannot be considered the technology with the scalability. The achievement of the scalability is require for really use from small network to large network. This mean technolohy require less configuration. 4.3. Simple install strategy In general, the tunnel technique is a technology that makes a virtual link between two arbitrary interfaces. Flexibility is very high. However, such flexibility may causes the recursive tunnelung ( tunnel in tunnel), and cause the difficulties for management and the trouble shooting. It is thought that this flexiblity make difficultly for large-scale development. That mean simple install strategy is required for avoiding such problems. 4.4. Can treat both IPv4 Global and IPv4 Privates For applying backbone networks, it should treat stub network which used not only IPv4 global address but also IPv4 private address. Moreover, it should treat many networks which use IPv4 private address. It means it is unaffected in the reused address, or non gloablly unique addess. Moreover, it should not depend with the range of IP address. That mean it should be no dependence with the addresses used in stub networks. 4.5. Can install into varius networks It is preferable to be able to apply widely. For example, it should apply access network, backbone network, data- center network, enterprise network, etc. Moreover, It has no dependency with Layer two technology, such as wire and wireless. 5. IANA Considerations This document makes no request of IANA. Matsuhira Expires July 7, 2012 [Page 5] Internet-Draft Motivation for SA46T January 2012 Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations Security consideration does not discussed in this memo. 7. Acknowledgements SA46T implementation was tested in Fujitsu, WIDE camp network in Septemper 2010, and NICT JGN2Plus testbed in February 2011. And SA46T was demonstrated at Interop 2011 Tokyo in June 2011. The author would like to thank all the people who assist, support and help above tests and demonstration, especially WIDE camp network team, NICT JGN2Plus / JGN-X team, Interop Shownet NOC team and in Fujitsu. Originally, SA46T is an abbreviation for "Stateless Automatic IPv4 over IPv6 Tunneling". Now, SA46T is an abbreviation for "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology". This change was made in response to the indication from the softwire WG chair at 4th softwire interim meeting in September 2011. 8. References 8.1. Normative References [I-D.draft-matsuhira-sa46t-as] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing", April 2011. [I-D.draft-matsuhira-sa46t-spec] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling: Specification", July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References Matsuhira Expires July 7, 2012 [Page 6] Internet-Draft Motivation for SA46T January 2012 Author's Address Naoki Matsuhira Fujitsu Limited 1-1, Kamikodanaka 4-chome, Nakahara-ku Kawasaki, 211-8588 Japan Phone: +81-44-754-3466 Fax: Email: matsuhira@jp.fujitsu.com Matsuhira Expires July 7, 2012 [Page 7]