Network Working Group N. Matsuhira
Internet-Draft Fujitsu Limited
Intended status: Informational January 6, 2013
Expires: July 10, 2013
Motivation for developing Stateless Automatic IPv4 over IPv6
Encapsulation / Decapsulation Technology (SA46T)
draft-matsuhira-sa46t-motivation-03
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 10, 2013.
Copyright Notice
Copyright (c) 2013 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 10, 2013 [Page 1]
Internet-Draft Motivation for SA46T January 2013
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 10, 2013 [Page 2]
Internet-Draft Motivation for SA46T January 2013
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 10, 2013 [Page 3]
Internet-Draft Motivation for SA46T January 2013
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 10, 2013 [Page 4]
Internet-Draft Motivation for SA46T January 2013
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 10, 2013 [Page 5]
Internet-Draft Motivation for SA46T January 2013
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", January 2013.
[I-D.draft-matsuhira-sa46t-spec]
Matsuhira, N., "Stateless Automatic IPv4 over IPv6
Tunneling: Specification", January 2013.
[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 10, 2013 [Page 6]
Internet-Draft Motivation for SA46T January 2013
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 10, 2013 [Page 7]