[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Network Working Group                                       N. Matsuhira
Internet-Draft                                           Fujitsu Limited
Intended status: Informational                              July 3, 2011
Expires: January 4, 2012


 Motivation for developing Stateless Automatic IPv4 over IPv6 Tunneling
                                (SA46T)
                  draft-matsuhira-sa46t-motivation-00

Abstract

   This document describe a motivation for developing IPv4 over IPv6
   Tunneling solution from standing position of Stateless Autimatic IPv4
   over IPv6 Tunneling (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 January 4, 2012.

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



Matsuhira                Expires January 4, 2012                [Page 1]


Internet-Draft            Motivation for SA46T                 July 2011


   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 January 4, 2012                [Page 2]


Internet-Draft            Motivation for SA46T                 July 2011


1.  Introduction

   This document describe a motivation for developing IPv4 over IPv6
   Tunneling solution from standing position of Stateless Automatic IPv4
   over IPv6 Tunneling (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 January 4, 2012                [Page 3]


Internet-Draft            Motivation for SA46T                 July 2011


   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 tunneling 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 January 4, 2012                [Page 4]


Internet-Draft            Motivation for SA46T                 July 2011


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 January 4, 2012                [Page 5]


Internet-Draft            Motivation for SA46T                 July 2011


   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.


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 January 4, 2012                [Page 6]


Internet-Draft            Motivation for SA46T                 July 2011


Author's Address

   Naoki Matsuhira
   Fujitsu Limited
   17-25, Shinkamata 1-chome, Ota-ku
   Tokyo,   144-8588
   Japan

   Phone: +81-3-6424-6270
   Fax:
   Email: matsuhira@jp.fujitsu.com








































Matsuhira                Expires January 4, 2012                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/