Internet Engineering Task Force I. Yamagata
Internet-Draft Y. Shirasaki
Intended status: Informational NTT Communications
Expires: January 13, 2011 A. Nakagawa
Japan Internet Exchange (JPIX)
J. Yamaguchi
IIJ
H. Ashida
iTSCOM
July 12, 2010
NAT444draft-shirasaki-nat444-02
Abstract
This document describes one of the network models that are designed
for smooth transition to IPv6. It is called NAT444 model. NAT444
model is composed of IPv6, and IPv4 with Large Scale NAT (LSN).
NAT444 is the only scheme not to require replacing Customer Premises
Equipment (CPE) even if IPv4 address exhausted. But it must be noted
that NAT444 has serious restrictions i.e. it limits the number of
sessions per CPE so that rich applications such as AJAX and RSS feed
cannot work well.
Therefore, IPv6 which is free from such a difficulty has to be
introduced into the network at the same time. In other words, NAT444
is just a tool to make IPv6 transition easy to be swallowed. It is
designed for the days IPv4 and IPv6 co-existence.
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 13, 2011.
Yamagata, et al. Expires January 13, 2011 [Page 1]

Internet-Draft NAT444 July 20101. Introduction
The only permanent solution of the IPv4 address exhaustion is to
deploy IPv6. Now, just before the exhaustion, it's time to make a
transition to IPv6.
After the exhaustion, unless ISP takes any action, end users will not
be able to get IPv4 address.
The servers that have only IPv4 address will continue to exist on the
Internet after the IPv4 address exhaustion. In this situation, IPv6
only hosts cannot reach IPv4 only hosts.
This document explains NAT444 model that bridges the gap between the
coming IPv6 Internet and the present IPv4 Internet.
2. Definition of NAT444 Model
NAT444 Model is a network model that uses two Network Address and
Port Translators (NAPTs) with three types of IPv4 address blocks.
The first NAPT is in CPE, and the second NAPT is in Large Scale NAT
(LSN) [I-D.nishitani-cgn]. LSN is supposed to be installed in the
ISP's network.
The first IPv4 address block is Private Address [RFC1918] inside CPE.
The second one is an IPv4 Address block between CPEs and LSN. The
third one is IPv4 Global Addresses that is outside LSN. The ISPs
using NAT444 provide IPv6 connectivity by dual stack model.
(The IPv4 Internet) (The IPv6 Internet)
| |
+---------+ |
IPv4 Global Address | |
+--------+--------+ |
| LSN | |
+--------+--------+ |
IPv4 | | IPv6
+-------------+
Dual Stack |
+---------------+----------------+
| IPv4 NAT/IPv6 Dual Stack CPE |
+---------------+----------------+
IPv4 Private Address / |
IPv6 Dual Stack |
+-----------+-------------+
|IPv4/IPv6 Dual Stack host|
Yamagata, et al. Expires January 13, 2011 [Page 3]

Internet-Draft NAT444 July 2010
support inspecting and rewriting the packets.
- Because both IPv4 route and IPv6 route exist, it doubles the number
of IGP route inside the LSN.
- UPnP doesn't work with double NAPTs.
5. Acknowledgements
Thanks for the input and review by Shin Miyakawa, Shirou Niinobe,
Takeshi Tomochika, Tomohiro Fujisaki, Dai Nishino, JP address
community members, AP address community members and JPNIC members.
6. IANA Considerations
There are no IANA considerations.
7. Security Considerations
Each customer inside a LSN looks using the same Global Address from
outside an ISP. In case of incidents, the ISP must have the function
to trace back the record of each customer's access without using only
IP address.
If a Global Address of the LSN is listed on the blacklist, other
customers who share the same address could be affected.
8. References8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[I-D.nishitani-cgn]
Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-nishitani-cgn-04 (work in progress),
March 2010.
Yamagata, et al. Expires January 13, 2011 [Page 6]