One document matched: draft-shirasaki-nat444-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC4925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4925.xml">
<!ENTITY I-D.ietf-behave-lsn-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-lsn-requirements.xml">
<!ENTITY I-D.shirasaki-nat444-isp-shared-addr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444-isp-shared-addr.xml">
<!ENTITY I-D.shirasaki-isp-shared-addr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-isp-shared-addr.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-shirasaki-nat444-06" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="NAT444">
NAT444</title>
<author fullname="Ikuhei Yamagata" initials="I." surname="Yamagata">
<organization abbrev="NTT Communications">
NTT Communications Corporation</organization>
<address>
<postal>
<street>Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku</street>
<city>Tokyo</city>
<code>108-8118</code>
<country>Japan</country>
</postal>
<phone>+81 3 6733 8671</phone>
<email>ikuhei@nttv6.jp</email>
</address>
</author>
<author fullname="Yasuhiro Shirasaki" initials="Y." surname="Shirasaki">
<organization abbrev="NTT Communications">
NTT Communications Corporation</organization>
<address>
<postal>
<street>NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku</street>
<city>Tokyo</city>
<code>100-8019</code>
<country>Japan</country>
</postal>
<phone>+81 3 6700 8530</phone>
<email>yasuhiro@nttv6.jp</email>
</address>
</author>
<author fullname="Akira Nakagawa" initials="A." surname="Nakagawa">
<organization abbrev="Japan Internet Exchange (JPIX)">
Japan Internet Exchange Co., Ltd. (JPIX)</organization>
<address>
<postal>
<street>Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku</street>
<city>Tokyo</city>
<code>100-0004</code>
<country>Japan</country>
</postal>
<phone>+81 90 9242 2717</phone>
<email>a-nakagawa@jpix.ad.jp</email>
</address>
</author>
<author fullname="Jiro Yamaguchi" initials="J." surname="Yamaguchi">
<organization abbrev="Fiber 26 Network">Fiber 26 Network Inc.</organization>
<address>
<postal>
<street>Haraguchi bldg., 5F, 3-11-4 Kanda Jinbo-cho, Chiyoda-ku</street>
<city>Tokyo</city>
<code>101-0051</code>
<country>Japan</country>
</postal>
<phone>+81 50 3463 6109</phone>
<email>jiro-y@f26n.jp</email>
</address>
</author>
<author fullname="Hiroyuki Ashida" initials="H." surname="Ashida">
<organization abbrev="IS Consulting G.K."> IS Consulting G.K.</organization>
<address>
<postal>
<street>12-17 Odenma-cho, Nihonbashi, Chuo-ku</street>
<city>Tokyo</city>
<code>103-0011</code>
<country>Japan</country>
</postal>
<email>assie@hir.jp</email>
</address>
</author>
<date month="July" year="2012" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Carrier-Grade,NAT</keyword>
<abstract>
<t>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 Carrier Grade (CGN).</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>After the exhaustion, unless ISP takes any action, end users will not be able to get IPv4 address.</t>
<t>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.</t>
<t>This document explains NAT444 model that bridges the gap between the coming IPv6 Internet and the present IPv4 Internet.</t>
</section>
<section title="Definition of NAT444 Model">
<t>NAT444 Model is a network model that uses
two Network Address and Port Translators (NAPTs)
with three types of IPv4 address blocks.</t>
<t>The first NAPT is in CPE, and the second NAPT is in
<xref target="I-D.ietf-behave-lsn-requirements">Carrier Grade NAT (CGN)</xref>.
CGN is supposed to be installed in the ISP's network.</t>
<figure><artwork><![CDATA[
(The IPv4 Internet) (The IPv6 Internet)
| |
+---------+ |
IPv4 Global Address | |
+--------+--------+ |
| CGN | |
+--------+--------+ |
IPv4 | | IPv6
+-------------+
Dual Stack |
+---------------+----------------+
| IPv4 NAT/IPv6 Dual Stack CPE |
+---------------+----------------+
IPv4 Private Address / |
IPv6 Dual Stack |
+-----------+-------------+
|IPv4/IPv6 Dual Stack host|
+-------------------------+
]]></artwork></figure>
<t>The first IPv4 address block is
<xref target="RFC1918">Private Address</xref> inside CPE.
The second one is an IPv4 Address block between CPEs and CGN.
The third one is IPv4 Global Addresses that is outside CGN.
The ISPs using NAT444 provide IPv6 connectivity by dual stack model.</t>
</section>
<section anchor="behavior" title="Behavior of NAT444 Model">
<t>The IPv6 packets from the host reach the IPv6 Internet without using NAT functionality.</t>
<t>The following figure shows the behavior of the IPv4 packet from the host to the IPv4 server via two NATs. The first NAT in CPE overwrites the Source IP Address and Source Port from 10.0.0.2:tt to w.w.w.w:uu. Then the second NAT in CGN overwrites them from w.w.w.w:uu to y.y.y.y:vv.
Destination IP Address and Port are not overwritten.</t>
<figure><artwork><![CDATA[
+-------------+
(Port=80) | IPv4 Server | ^
x.x.x.x-> +------+------+ :
| :
IPv4 Global Address | :
| :
(The IPv4 Internet):(Dst=x.x.x.x:80/Src=y.y.y.y:vv)
| :
IPv4 Global Address | :
| :
y.y.y.y-> +----+----+ :
(Port=vv) | CGN | ^
z.z.z.z-> +----+----+ :
| :
IPv4 Address | :(Dst=x.x.x.x:80/Src=w.w.w.w:uu)
| :
w.w.w.w-> +-------+-------+ :
(Port=uu) | IPv4 NAT CPE | ^
10.0.0.1-> +-------+-------+ :
| :
IPv4 Private Address| :
| :
10.0.0.2-> +----+----+ :(Dst=x.x.x.x:80/Src=10.0.0.2:tt)
(Port=tt) |IPv4 Host|
+---------+
]]></artwork></figure>
<t>The following figure explains the behavior of returning IPv4 packet via two NATs. The first NAT in CGN overwrites the Destination IP Address and Port Number from y.y.y.y:vv to w.w.w.w:uu. Then the second NAT in CPE overwrites them from w.w.w.w:u to 10.0.0.2:tt.</t>
<figure><artwork><![CDATA[
+-------------+
(Port=80) | IPv4 Server | :
x.x.x.x-> +------+------+ :
| :
IPv4 Global Address | :
| :
(The IPv4 Internet):(Dst=y.y.y.y:vv/Src=x.x.x.x:80)
| :
IPv4 Global Address | :
| :
y.y.y.y-> +----+----+ :
(Port=vv) | CGN | v
z.z.z.z-> +----+----+ :
| :
IPv4 Address | :(Dst=w.w.w.w:uu/Src=x.x.x.x:80)
| :
w.w.w.w-> +-------+-------+ :
(Port=uu) | IPv4 NAT CPE | v
10.0.0.1-> +-------+-------+ :
| :
IPv4 Private Address | :(Dst=10.0.0.2:tt/Src=x.x.x.x:80)
| :
10.0.0.2-> +----+----+ :
(Port=tt) |IPv4 Host| v
+---------+
]]></artwork></figure>
</section>
<section anchor="proscons" title="Pros and Cons of NAT444 Model">
<section anchor="pros" title="Pros of NAT444 Model">
<t>This network model has following advantages.</t>
<t> - This is the only network model that doesn't require replacing CPEs those are owned by customers.<vspace blankLines="0" />
- This network model is composed of the present technology.<vspace blankLines="0" />
- This network model doesn't require address family translation.<vspace blankLines="0" />
- This network model doesn't require DNS rewriting.<vspace blankLines="0" />
- This network model doesn't require additional fragment for the packets because it doesn't use tunneling technology.</t>
</section>
<section anchor="cons" title="Cons of NAT444 Model">
<t>This network model has some technical restrictions.</t>
<t>- Some application such as SIP requires special treatment,
because IP address is written in the payload of the packet.
Special treatment means application itself aware double NAPT
or both of two NAPTs support inspecting and rewriting the packets.
<vspace blankLines="0" />
- Because both IPv4 route and IPv6 route exist,
it doubles the number of IGP route inside the CGN.
<vspace blankLines="0" />
- UPnP doesn't work with double NAPTs.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA considerations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Each customer inside a CGN 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.</t>
<t>If a Global Address of the CGN is listed on the blacklist,
other customers who share the same address could be affected.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC1918;
&RFC4925;
&I-D.ietf-behave-lsn-requirements;
</references>
<references title="Informative References">
&I-D.shirasaki-isp-shared-addr;
&I-D.shirasaki-nat444-isp-shared-addr;
</references>
<section anchor="transition" title="Example IPv6 Transition Scenario">
<t>The steps of IPv6 transition are as follows.</t>
<t>Step 1: Enabling softwire client in host</t>
<t>ISP provides IPv6 connectivity to customers with <xref target="RFC4925">softwire</xref>. ISP installs CGN and softwire concentrator in its network. A softwire client in host connects to the IPv6 internet via ISP's concentrator.
ISP can use existing IPv4 equipments. Customers can just use existing CPE.</t>
<figure><artwork><![CDATA[
(The IPv4 Internet) (The IPv6 Internet)
| | IPv6
| +-----------+-----------+
| | Softwire Concentrator |
| +-----------+-----------+
+---------+----------+ ^
IPv4 Global Address | :
+----------+----------+ :
| CGN | :
+----------+----------+ :
Any IPv4 Address | : IPv6 over IPv4 Softwire
(ISP Network) | : (e.g. IPv6 over IPv4 L2TP)
+----------+----------+ :
| IPv4 NAT only CPE | :
+----------+----------+ :
IPv4 Private Address | v
+---------------+-----------------+
|IPv4/IPv6 Softwire Client in host|
+---------------------------------+
]]></artwork></figure>
<t>Step 2: Enabling softwire client in CPE</t>
<t>A customer enables softwire client in CPE. A softwire client in CPE connects to the IPv6 internet via ISP's concentrator. A Customer's network is now dual stack.</t>
<figure><artwork><![CDATA[
(The IPv4 Internet) (The IPv6 Internet)
| | IPv6
| +----------+------------+
| | Softwire Concentrator |
| +----------+------------+
+---------+------------+ ^
IPv4 Global Address | :
+----------+------------+ :
| CGN | : IPv6 over IPv4 Softwire
+----------+------------+ : (e.g. IPv6 over IPv4 L2TP)
Any IPv4 Address | :
(ISP Network) | v
+---------------+--------------------+
|IPv4 NAT/IPv6 Softwire client in CPE|
+---------------+--------------------+
IPv4 Private Address / |
IPv6 Dual Stack |
+-----------+-------------+
|IPv4/IPv6 Dual Stack host|
+-------------------------+
]]></artwork></figure>
<t>Step 3: Moving on to dual stack</t>
<t>ISP provides dual stack access to CPE. A CPE uplink is now dual stack.</t>
<figure><artwork><![CDATA[
(The IPv4 Internet) (The IPv6 Internet)
| |
+---------+ |
IPv4 Global Address | |
+--------+--------+ |
| CGN | | IPv6
+--------+--------+ |
Any IPv4 Address / | |
IPv6 Dual Stack +-------------+
(ISP Network) |
+---------------+----------------+
| IPv4 NAT/IPv6 Dual Stack CPE |
+---------------+----------------+
IPv4 Private Address / |
IPv6 Dual Stack |
+-----------+-------------+
|IPv4/IPv6 Dual Stack host|
+-------------------------+
]]></artwork></figure>
<t> Step 4: Moving on to pure IPv6</t>
<t>IPv6 transition completes.</t>
<figure><artwork><![CDATA[
(The IPv6 Internet)
|
IPv6 |
+--------+----------+
| IPv6 CPE |
+--------+----------+
IPv6 |
+--------+----------+
| IPv6 host |
+-------------------+
]]></artwork></figure>
</section>
<!-- Change Log
v00 2008-06-09 YS Initial version (was: isp-shared-addr)
v01 2008-10-24 YS NAT444
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:52:33 |